2

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?

  • What part of Autobahn do you think does not support a secure scheme? (the js lib just blindly uses whatever URL you throw at it). – symcbean Jan 6 '16 at 15:02
  • Autobahn|Python with Asyncio doesn't support secure WebSockets as far as I can tell. I was unable to find any documentation on the main website, do you have a link that says otherwise? I'd love to see it! – sethmlarson Jan 6 '16 at 15:18
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.

  • Ah that's true, still can replay without a server-generated token. Can't believe I didn't think of that, haha.I'll add the token method you describe, the reason I wasn't using one initially is that I was envisioning having a cookie based "stay-logged-in" system per machine, then when you visit the page again the client simply sends a "restore session" request to the server and the server validates the request and the user if it's correct. – sethmlarson Jan 6 '16 at 16:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.