Dr Brain

That whole side of the zone (the area bots and the ?buy system) grew out of a bet with Nikon F5 to show he was doing *his* buy system wrong. My original focus for the zone was on the Hypertunnels and FTLs (like the aforementioned catapults). In retrospect, that should pretty much explain everything that's ever happened in the zone.

Obviously the website would use HTTPS, but it's far easier to create a website than it to use TLS and some zone tunneling system to get the biller and client to talk directly. Plus you have to figure out how to get the info to the zone, which is an extra complication. There's also the question of what >5000 open TLS sockets will do to a billing server. I shudder to think. It could be made to work, of course, but the scheme I proposed has the advantages of being (relatively) simple, not requiring public key distribution, and working with UDP based protocols like SS currently enjoys.

That's the easy part. Signups and password changes are only allowed through the (hypothetical, remember) online interface. No zone involvement at all, so no trust issues. Doesn't have to be connected directly to the biller (or even be hosted on the same box), but it would need database access. As for database leaks, yes they could get the SHA256(password) and use that to impersonate a player with a custom client or hacked zone if the leak went undetected, but I don't really see any way around that. A detected leak you could just reset all passwords in the database and send out an email asking people to reenter their password using the online interface. You could increase security for the stored password by using a salt. I think our terminology is getting a bit messy in this discussion. The other salts we've been discussing are really nonces (numbers used only once). A salt (as I've always heard the term) is used to protect data at rest, and a nonce is used to protect data in transmission. They're used synonymously a lot of times, but in this particular discussion we have both so I'll try to make an effort to use the correct terms from now on. So the client would store SHA256(raw password) on disk. I don't think this can be secured any further (while still allowing players to save their password for the client). The biller would store salt & SHA256(SHA256(raw password) + salt), salt being a random number generated when the password is created/updated. Prevents any database leaks from compromising the player's raw passwords. The client would send the biller SHA256(SHA256(raw password) + salt) + SHA256(nonce + cnonce) + player name). Nonce is generated by the biller, cnonce is generated by the client. I'm not sure it's necessary to hash the nonce and cnonce together, but I've seen it done so there may be a valid reason. The real problem with asymmetric encryption is the distribution of the public keys through a trusted channel. If there were only one server, like the SSC biller in SS, then you could hard-code it or otherwise include it with the client. But if you've got the possibility for multiple billers, it becomes a huge problem. Not worth it, in my opinion. There may be a clever way to use the password exchange as a verification of public keys between the client and biller, to exchange a common secret (to use with a symmetric cypher like AES). I haven't given it enough thought. If you could manage this, then you could encrypt the biller communication, like chat messages, biller ?commands and private messages (there's no technical reason the zone needs to handle private messages).

That's easily solved by making the salt a combination of random numbers from the client as well as the biller. Asymmetric encryption is way overkill. You can also throw other things into the hash, like the player name for good measure. I've been working with hardware crypto systems at work, so I've had a lot of exposure to how experts design these things (though that doesn't make me an expert myself).

I don't see how it makes things weak. Presumably the salt would be a something like a SHA256 hash on a (true) randomly seeded PRNG. Lets say worst case scenario, the user hits reconnect 10 times before the zone lets them in, every time they connect, 10 times a day, over their entire play period of 10 years, never changing their password. The malicious zone gets 365250 salt responses. This seems like a large number only until you compare it to the 2^256 keyspace of the salts. It's only weak if the zone can make the client hash on demand, thousands or millions of times per second. Cheese is right. A central auth server would be the obvious target for a DDoS to take down the entire game. That's why the SSC biller is behind an firewall with IP whitelist. It's not about capacity, but defending single points of failure. Even a distributed biller would have this problem.

You don't have to check the password, or even involve a client to do that. If you've got such a big hole in your biller that it will accept commands for players that aren't even logged in, you have way bigger issues (like the fact that your biller was written by a moron). Billers have to track which players are online and which zones they're in to do chat channel routing anyway. It's not "extra" effort.

In that situation the biller wouldn't accept the hashed pw+salt as valid, since it wasn't hashed using the correct salt.

It will be hard to get into the mainline ASSS, not because anyone is opposed to it, but rather because the maintainers aren't really active any more. Best way to get people to use it will be a source release and a few pre-built binaries for common systems.

... three and a half years later...

https://dl.dropboxusercontent.com/u/7248473/zones.7z I removed the private maps, since I didn't feel right about revealing the names of private arenas. There's about a thousand different copies of HS you'll have to sort through, though.

I just wanted to mention it, because Sass ... isn't a team player.

Just be sure to note that it's unofficial if it doesn't come from someone working for the zone.

Nice. You missed one between the 'a' and 'c'.

Ditch the rocks. Keep the starfield. Looking good.

If you could capitalize the second S it'd be even better. That's probably pretty difficult though.

Back up.

Back up.

Seriously? You want unrealistic realism?

I think whoever is behind this doesn't realize that even if the game gets voted in, the effort will still fail. It will fail because no one has the source except PriitK, and PriitK can't give it up because he'd be sued by his employer (disclaimer: this is my hypothesis and it makes sense, but I *could* be wrong). Best case scenario, it'll get greenlit then be cancelled.

Sorry, I just grabbed the most recent copy I had without actually testing it. Guess it was still too old. I wonder what happened to the newer version(s)...

Found a copy in my backups. Here you go: https://dl.dropboxusercontent.com/u/7248473/SignedChatnut.jar

AI ships are fairly difficult to manage. believe it or not it's stupid things like making them so they don't fly through walls and take damage and die that are the hardest.

Actually, that's pretty much the definition. If you can't play with other people using the "same game" then it's not the same game. There are no shades of "different game". Either it's the same game or it's not. In this case, it's not. Phoenix's success won't alter SubSpace's fate.

And why should we believe you over the guy *writing* the new game? By your logic, continuum is the same game as asteroids.