Security of Web Game over WebSockets?

Question

Project that I'm working on depends on WebSockets to communicate between the server and client browser for all interactions within the game. I'm attending university for Computer Security, but I'm still unsure about potential attacks against the current validation system.

I'll start off real quick and say that at this current time I cannot use Secure WebSockets due to Autobahn (still ) not supporting Secure WebSockets. If I have to change my framework that I'm using to solve any problems I will though.

As it works right now, on connecting the user requests the server's public key (2048 bits) which can be changed at a regular interval, server gives the public key to user. To validate the key a quick exchange of sending a constant known string encrypted with the key is sent to the server and the server verifies the key is correct to the user. After verifying the key, the client encrypts the plain-text password provided by the user and sends it to the server. Server decrypts password, hashes password with bcrypt and validates the password in a timing-attack resistant way (No early out, nearly constant runtime). Encryption uses a randomized nonce as a part of the padding to prevent replay-attacks.

The part I'm most suspect about is how my current implementation "tracks" which socket belongs to who. Basically if a "login" request is handled by a socket and the result is positive then the socket gets "named" by setting a special attribute on the socket to the username provided in the login request.

On disconnection the socket is destroyed and there are staleness checks for sockets that haven't received a request in a long time to be automatically logged out. The only way to set the attribute on a socket server-side is to perform a successful login request.

I'm aware of the MITM attack possibility regarding the key exchange.

My concerns are what are the flaws in this system, and how should I prevent or mitigate them?

Answer 1

Essentially, you have a password equivalent string (the public key encrypted password), which is sort of protected by the requirement for the constant string to be sent. However, if it is a constant string, an attacker could just replay an old call - they can get the key (it's public) after all. The randomised nonce must also be transferred to the client, or be generated on the client - either way, since it happens before authorisation, an attacker can presumably get it.

It might be worth considering including some form of token in all requests, effectively decoupling the specific socket from a given user and therefore bypassing your main area of concern - presumably it doesn't really matter which socket a user comes in on, as long as you can prove that the request comes from a specific authorised user. This also has the advantage of allowing the same backend processes to handle alternative login methods (for example, if you added an API to your application for mobile application use). This also ensures that user sessions can be continued over a restart of the server side process - currently, from the sounds of it, your users would find themselves logged out if you had to restart the server process, even if the process restart was momentary. Presumably, the flags on specific sockets wouldn't be set in this case, without a new login.