I'm creating a multiplayer game(based in websockets) which runs directly from the browser and which has multiplayer functionality. Each player needs to have his own account(Username and password). When I was planning the game, I realized that the easiest way to migrate it to other platforms is writing it in HTML5. So, I need to create a login system using JS and websockets. But I'm not sure of how secure is to send a message with a content like username and password to the websocket server(which runs in a Java virtual machine).
Add a comment
|
2 Answers
If you want security, transmitting authentication data through TLS is a big start. But let's assume the websocket is already set up over TLS. A solution I would recommend would be based on a challenge-response mechanism :
- The server would set up a random set of bytes (the challenge), set a timeout at the end of which the challenge wouldn't be authorized.
- The client would send in "plain text" the username and the challenge and an hash (with a SHA2 or SHA3 algorithm) of
challenge || username || f(password),f(password)being how the password is stored in the database (a SHA256 ofpasswordfor instance). - The server verifies with the username's data and the challenge the response and if so, authenticates the user. It also invalidates the challenge to invalidate any future attempt using this challenge.
This method provides an anti-replay functionality : an attacker could not capture the data and replay it later to authenticate.
I however have one big problem with this method : f(password) has here the roughly same security as password : if the database leaks, any attacker could authenticate as anybody else. I say "roughly" because, if stored in clear text, since a lot of users are using the same password on multiple websites (which is bad), their accounts could be compromised elsewhere.
I can't think of a method protecting against a database leakage and an anti-replay mechanism, but an anti-database leakage mechanism (send user password in clear text over TLS, hash password with database salt and compare with database) over TLS should be sufficient enough against most risks you will face
-
1Don't invent your own algorithms. Yours for example can be improved by the server sending salt, challenge and iteration count at the beginning, and the client doing
H(challenge || username || BCRYPT(it, password, salt)). Then the server can storeBCRYPT(it, password, salt))in the DB. Commented Nov 18, 2014 at 1:58 -
1If "the websocket is already set up over TLS" then there's no need for anything else here.– user49075Commented Nov 18, 2014 at 4:45
-
1@RickyDemer Yes, there is a need for more. HTTP over TLS is different from WS over TLS. They are completely different connections that may just happen to come through the same client... or could come through the same proxy or through the same MitM. They both have different, distinct TLS handshakes, thus without a client certificate, the client isn't authenticated through TLS, and needs to be separately authenticated through both HTTP and WS. Commented Jul 22, 2015 at 16:09
If you want passwords, the best way is to use TLS, and then send the passwords in clear. This is simpler than a challenge-response mechanism.
If you however can't have TLS for websockets, but you have TLS for the code (delivered over HTTP), best thing to do is to do the login via HTTPS, generate session cookies (or some other form of keys) and use them to authenticate to the websocket. If you make challenge-response in the clear, an attacker can brute-force the password using that communication. With the session approach, an attacker can only capture the session of your (un-sensitive) game, but not the (possibly re-used) password. However when you have TLS on neither, you should let users authenticate through third parties, e.g. through OpenID. Then you don't need to handle sensitive data like passwords. OpenID is a good option for the other cases too.
