ASSS ChatNet update

[X-Demo]

I didn't like the idea that ASSS's ChatNet protocol is raw text (including passwords).  So I've been working on updating ASSS's ChatNet module.

 

The features I'm working on are:

• SSL encryption [DONE]
• WebSocket support [DONE]
• Required Biller Login (ie. logins will be denied if the billing connection has been lost) [DONE]
• 1 shot HTTP credential verification [SKIPPED]
• Rigorous testing of the new features/code [COULD ALWAYS USE MORE ]

 

When I finish, I'm hoping ASSS will accept my changes otherwise I can provide the module in binary/source form.

 

With WebSocket w/ TLS encryption (WSS) I'm hoping to create an HTML5 SS web-chat site that connects directly to an ASSS-enabled zone w/ the updated ChatNet module.

 

With the 1 shot HTTP credential verification (and required biller login), I'm hoping to create an OpenId service that will allow both the web-chat and other websites to enable logins using your Subspace/Continuum login credentials, like how you can log in to/register with certain websites with your Facebook/Twitter/LinkedIn/Google credentials.  Although without multiple ASSS servers running the new code, this won't be reliable; a problem since failover capabilities/high-availability is pretty much a necessity for services other sites depend on.

 

--Updates--

9/23/2013:

  -Fixed the "crash bug" (was a debug assertion that lead me to the actual bug)

  -Forked ASSS on Bitbucket  (still hoping to get the changes pulled back)

 

9/30/2013:

  -Can't test the Windows build with Continuum due to ancient security.dll files and API breakages due to poor design (the design could be on purpose to make reverse engineering harder even though that's been done already apparently).

  -I'm debating reversing the ASSS security library anyways so I can release updated "security.dll/so" binaries that won't break as easily (static compiled [glibc version independent] if possible and unchanging APIs), as well as some for other platforms and architectures if requested.  (Currently I want one for Armv5te.)

  (Also, I'll have to make sure those binaries are at least as hard to reverse as the current ones.)

  -I plan to commit the current code to a branch in my forked repository although it needs quite a bit of work before I'll deem it ready for a pull request. (re-organization, cleanups, testing, valgrinding, porting to Linux, adding configuration directives for global.conf, README updates for how to generate SSL certs, etc)

 

11/02/2013:

  -My computer died, though not my hdd thankfully.  I took the opportunity to switch to Linux and now have my dev environment ready to go now.

  -While reverse engineering the security library I found out a few reasons why it's not more abstracted from the rest of the code.  I probably won't be spending more time on reversing it as I don't see the point.

 

11/09/2013:

  -I've committed my changes here: https://bitbucket.org/X-Demo/asss.

  -I'll be making the pull request to grelminar/asss shortly...

Edited November 10, 2013 by X-Demo

[Dr Brain]

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.

[JoWie]

Sounds very good. I wanted to make something very similar a while back (however I got completely fed up with asss and I quit making things with it). I've actually implemented a websocket server from scratch back when there were not many libs, for a different project haha (using one of the now obsolete drafts).

 

Did you actually integrate SSL yourself, or are you using a reverse proxy like nginx?

[Cheese]

this is sounding pretty good, and i might ask you later to contribute to the new client

[X-Demo]

@Dr Brain:  I was hoping to get ASSS repo access on Bitbucket to a feature branch so it could be looked over and played with easily.  Also I had a bunch of MinGW build fixes I had hoped to get off my hands that might clutter up my patch, lol.  Maybe I'll just clone the repo and get my branches that way .  Speaking of fixes, not only do I want to fix up all the warnings I can when building (MinGW is almost a hopeless case due to the windows compat hacks), it might also be fun to try compiling ASSS with clang as that might generate even more warnings.

 

@Jowie:  I integrated it myself, though since I began developing using Windows I found that MinGW's OpenSSL just repeatedly crashed.  When I switched OpenSSL's official? Windows installer (http://slproweb.com/products/Win32OpenSSL.html) it worked like a charm.  Furthermore, I found a way to share the same TCP port ChatNet is using to support both plain and SSL encrypted connections on the same port!

 

@Cheese:  Certainly a possibility, I've been looking into Discretion a lot lately but since it plain just crashed when I first ran it I'm not sure how far along it got .  I've also been looking into Python-OGRE and other mixes of higher(ish) level gaming SDKs.  With the idea of not reinventing the wheel and speeding up development using higher-level languages.  Though that approach kinda conflicts with really wanting an authoritative server (like Counter Strike has, etc) for security/lag mitigating purposes.

Edited September 23, 2013 by X-Demo

[X-Demo]

When I realized that making an OpenId provider was possible and that high-availability was a necessity, I started thinking that doing it this way is not exactly ideal.  In my mind, ideally, the OpenId service should be working with the authoritative source of the auth data - the biller itself.

 

I'd much rather find a way to work with the SSC biller directly - though I've been lead to believe getting access to this is extremely hard to get lately.  Truely unfortunate given availability of so many public authentication systems like OpenId.

 

With SS OpenId it may even be possible to at least allow SSC logins to work with a modified ASSS server without SSC billing...  Although, many things wouldn't work right, like ?usage, scores?, chats, squads, etc.

[Resol]

With SS OpenId it may even be possible to at least allow SSC logins to work with a modified ASSS server without SSC billing...  Although, many things wouldn't work right, like ?usage, scores?, chats, squads, etc.

 

What you mean get SSC logins to work without SSC billing exactly? And what would be the point if nothing was actually connected to SSC?

[X-Demo]

 

With SS OpenId it may even be possible to at least allow SSC logins to work with a modified ASSS server without SSC billing...  Although, many things wouldn't work right, like ?usage, scores?, chats, squads, etc.

 

What you mean get SSC logins to work without SSC billing exactly? And what would be the point if nothing was actually connected to SSC?

 

 

Essentially indy ASSS servers could use SSC credentials... But now that I think about it, it's a major security issue just waiting to happen.  For example, can indy ASSS zones be trusted not to steal your SSC password?

[Resol]

I'm sorry, but I still don't see what the point is, or the reason. 

 

Am I wrong in saying that a player can't just use their SSC "credentials" on other servers on their own?

[X-Demo]

I'm sorry, but I still don't see what the point is, or the reason. 

 

Am I wrong in saying that a player can't just use their SSC "credentials" on other servers on their own?

 

Hmm, I don't see why they "can't"...  Players "can" use any username and password they want as long as it's not taken / the password matches (doesn't matter whether the server is connected to the SSC biller, their own biller or not connected to a biller at all).

 

The whole point is that you can verify SSC login credentials without having to get access to the SSC biller directly.  Ideally this whole OpenId thing should be done directly with SSC biller but I figured I'd add the few lines of code it required as I've heard it's very hard to get access to the SSC biller.

 

Since Subspace.co isn't verifying SSC credentials, how would you know I'm the real X-Demo and didn't just type "X-Demo" into the name field when registering?  It also would've been irritating if someone already registered using "X-Demo" here before I did.

[Cheese]

ideally, i would want logins to work as follows:

 

player to zone: connect

zone to biller: player X online

biller to zone: crypto salt

zone to player: crypto salt

player client hashes pw using salt

player to zone: hash

zone to biller: hash

biller to zone: confirm/deny

zone to player: access granted/denied

[JoWie]

ideally, i would want logins to work as follows:

 

player to zone: connect

zone to biller: player X online

biller to zone: crypto salt

zone to player: crypto salt

player client hashes pw using salt

player to zone: hash

zone to biller: hash

biller to zone: confirm/deny

zone to player: access granted/denied

 

This is weak because a zone operator could make up its own salts.

[Dr Brain]

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

[Cheese]

i think hes saying that the zone could be told by biller that it was invalid pw and still allow user to login anyways

and that would be a huge security breach

 

 

so i suppose the biller could keep a log of access granted'd players and the servers they logged in under, and only accept commands for those

Edited October 4, 2013 by Cheese

[Dr Brain]

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.

[JoWie]

With weak I meant in the cryptography sense.

The zone server can make the client hash the password using any salt it wants (even if it was rejected by the biller, just fake a lagout and pass the normal salt the next time). This would make bruteforcing passwords much easier. (it gets even more dangerous if the salting is implemented incorrectly, lookup hmac and maybe scrypt).

 

You would also need to store the passwords as plain text in the authentication server. Of course you could add another layer of hashes, but that means the hash is your password now.

 

An easy fix would be to make the client go to the auth service on its own using TLS, authenticate there, and then the zone contacts the auth service to verify (like how openid works, as x-demo mentioned). Or I guess you could tunnel to the auth service through the zone, but that seems too complicated.

[Cheese]

but then you are having clients with open connections to the biller, and thats also very bad

 

or make a standalone auth server, and then you have +1 server and thats bad too

Edited October 6, 2013 by Cheese

[JoWie]

The client would only need to contact the biller/auth service to authenticate, register, change passwords. (unless you also want to secure cross zone chats).

The client would be able to drop his connection after authenticating.

 

You could probably easily handle 10'000+ connections concurrently using a single server (node.js, nginx, and a few others support this: http://synrc.com/lj/webcompare/connections.png ).

 

Imo, a separate auth service is good because it would let anyone run whatever biller or zone they want. Authentication is the only thing that _must_ be centralized. It would also be good if the auth service does not perform banning (unless someone abuses the auth service itself), this would prevent the current SSC-madness.

Edited October 6, 2013 by JoWie

[Dr Brain]

With weak I meant in the cryptography sense.

The zone server can make the client hash the password using any salt it wants (even if it was rejected by the biller, just fake a lagout and pass the normal salt the next time). This would make bruteforcing passwords much easier. (it gets even more dangerous if the salting is implemented incorrectly, lookup hmac and maybe scrypt).

 

You would also need to store the passwords as plain text in the authentication server. Of course you could add another layer of hashes, but that means the hash is your password now.

 

An easy fix would be to make the client go to the auth service on its own using TLS, authenticate there, and then the zone contacts the auth service to verify (like how openid works, as x-demo mentioned). Or I guess you could tunnel to the auth service through the zone, but that seems too complicated.

 

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.

 

The client would only need to contact the biller/auth service to authenticate, register, change passwords. (unless you also want to secure cross zone chats).

The client would be able to drop his connection after authenticating.

 

You could probably easily handle 10'000+ connections concurrently using a single server (node.js, nginx, and a few others support this: http://synrc.com/lj/webcompare/connections.png ).

 

Imo, a separate auth service is good because it would let anyone run whatever biller or zone they want. Authentication is the only thing that _must_ be centralized. It would also be good if the auth service does not perform banning (unless someone abuses the auth service itself), this would prevent the current SSC-madness.

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.

[JoWie]

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.

What I meant is that the client can not verify that the given salt comes from the biller (in the setup that he described). The

zone could just make the salt all 0:

 

player to zone: connect
zone to biller: player X online
biller to zone: salt=PRNG
zone to player: salt=0x00000 (or another fixed value)
player client hashes pw using salt (0x00000)
player to zone: hash
zone to player: some kind of error
zone: look up hash in a rainbow table of a dictionary

This attack could be prevented if you either have the client connect to the auth service on his own.

Or somehow verify the salt really comes from the auth service, or just encrypt the entire auth handshake.

Maybe there is another way to fix this (I am not an expert on encryption, I just pretend to be haha). But you probably need to use asymmetric encryption in most solutions.

 

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.

If you want a system where someone has to verify a zone before it is allowed to use the biller/auth service, that could be the better choice.

But if you want authentication to be open to all players and any random zone, it would not matter much if the attack was done by impersonating zones vs impersonating players.

 

As for denial of service, attacking the zones directly is probably a lot more effective (even if you would want to attack the top 50 of zones for example). They can not be distributed over multiple servers easily, require more resources, are more suspect to targeted attacks (like abusing the game protocol).

 

For an auth service which only has one simple purpose it is much more simpler. There are even online proxy services like cloudflare that could help such an auth service (the caching does not help much, however it hides the address to your real server and it auto blacklists attackers)

Edited October 6, 2013 by JoWie

[Dr Brain]

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).

[JoWie]

Ah, nice. This is why I made that original comment haha.

 

You would also need a hash back from the server with a second salt so that the client can verify the biller (if that is needed of course)

Edited October 6, 2013 by JoWie

[Cheese]

i really really like that double salting idea

[JoWie]

So if you do not want to use asymmetric encryption, how would you go about secure signups or password changing?

 

And what about database leaks? If the password is not sent to the biller, but only a hash, the database would need to store the password (or whatever is equivalent to the the thing that is put into the hash)

[Dr Brain]

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).