My login security design

[Greg]

Hi, guys, it's me again!

Like maybe you remember, I'm currently designing an online multiplayer game. I'd like to post my design of the client login structure here and ask you, if you see any security glitches. I would really appreciate any comments and help

My main goals were to:
-prevent other applications to connect with my private server
-prevent more than 1 people logged on the same account at the same time

1. Client types his Nickname and Password into 2 edit boxes. After clicking "OK" button, the password gets changed into MD5 string and along with the login, it gets sent to a PHP file on my server (as for now it's just POST, but I'm probably gonna try adding SSL).

2. The PHP file on the server connects with a MySQL database and checks if the password for the given login is correct. If yes, then it sends information about successful log in to the client.
Also, it puts his nickname, a randomly generated number and the session expiration time into another MySQL table called "sessions".

3. The client connects with the server using the login as the nickname.

4. The server checks if there's no player with that nickname on the players' list. If there is, then it refuses connection. If there's no, it sends the username to a PHP file.

5. The PHP file checks if there's a record containing the username sent by the server in the table "sessions". If yes, then it returns to the server the randomly generated number for that user.

6. The server encrypts the received number using the password of the joining user as a key (from the MySQL database) and sends the encoded string to that user.

7. The client decodes the string from server, using the password typed earlier by the user and then sends back the decrypted number to the server.

8. The server receives the number from the client and sends it to the PHP file.

9. The PHP file checks the number with the one in the "sessions" table. If it's correct, then it removes the session expiration time from the record (it won't be needed, since the record's gonna get removed if the user disconnects) and sends an information about a successfull log in to the server.

10. The server adds the nickname of joining player to the players' list.

(11). Each time client disconnects, the server removes informations about that player from the MySQL table "sessions".

(12). Every 1 minute, the server's gonna run a PHP script checking if there're any expired sessions and removing them.

What it gives:
-If some other application tries to connect to my server, then it's gonna get disconnected, because there won't be information about it in the MySQL database (which only server can access). (5)
-If somebody runs my client and logs in using his game account, his nick's gonna get added to the MySQL database, so he could then run his own application and connects to my server using his nickname from the game, because it is in the MySQL database. However, he won't be able to, because the server checks if there're no more than 1 player with the same nickname (4).
-If somebody logs in and doesn't connect to the game, his session's gonna expire after 1 minute. If during that 1 minute, anybody tries to connect with the server using the nickname saved in the "sessions" table, he won't be able to without knowing the password.

[Dynasoft]

It sounds ok.
Two comments/questions though:
Does the session in the database ever expire if the player logs in but then doesn't connect to the game for any reason?
It's vulnerable to replay attacks, if the communication from client to the login server is / is allowed to be identical every time. i.e. someone could record and replay a successful login, without ever actually knowing the password.

[Greg]

Good point, thank you!
I'm gonna make the sessions expire after some given time, if they're not being used

[Fimbul]

You send the password as plaintext, and the PHP server is responsible for MD5ing it (and scramble it a bit following a rule), and check that against your database. You don't store passwords in plaintext, but you can pass them as plaintext.

If the client sends an MD5 to the host, that MD5 effectively becomes the password, and any protection you might have is void.

Also, on replay attacks: don't bother avoiding them - too much trouble and minimal gain (unless you're a bank or something).

[Dynasoft]

It is true that if your client sends an md5 to the server then the md5 is effectively the password, but it's still slightly more secure than transmitting the password in cleartext because if someone snoops it they can't just type what they see into the real client.

Avoiding replay attacks is a simple as asking the server for a login token (which is generated randomly), and then making an md5 of that plus some secret salt (you should be using a salt anyway) plus the password (or the md5 of the password), and sending that back to the server. The server then does the same thing to validate the password, using the token it generated for you earlier.
i.e.
User signs up with "username" and "password"
Server stores md5(salt+password) into the database
User logs in by typing password into client
Client sends username to server, asking for login token
Server sends back token and stores token with username
Client computes md5(token+salt2+md5(salt+password)) and sends it to the server
Server computes md5(token+salt2+storedpasswordmd5) and checks if it matches
Server sends back login succeed/fail, and stores session if login success


EDIT: You don't need to avoid replay attacks, if you're willing to be slightly less secure. At least use a salt to prevent md5 reversing though.

[Greg]

I've changed it a bit, adding some encryptions and expiration of the sessions, you can see it in the first post.

[Dynasoft]

Why do you now seem to be checking the user's password twice?

[Greg]

I think I've got confused with my own ideas, let me think it over again...

EDIT:
I've changed it again, but it seems that it's still not good... If somebody logs in, there's gonna be a record with his username created in the "sessions" table, so he will be able to run any other application and make it connect with my server... :/

[Fimbul]

If somebody logs in, there's gonna be a record with his username created in the "sessions" table, so he will be able to run any other application and make it connect with my server... :/

If you mean "he will be able to multiclient" then no, because the other client will have to login. If he tries to login and his username is already stored in "sessions", either the old instance gets booted or the new instance gets an access denied (your choice, really).

If you mean "he will be able to plug third party applications in", then yes. But then again, he can plug anything anyways, unless you encrypt every outgoing packet, which you won't because no one has that kind of processing power (unless you're a bank).

but it's still slightly more secure than transmitting the password in cleartext because if someone snoops it they can't just type what they see into the real client.

If he knows how to snoop, then he knows how to replay. Little program called "WPE PRO" should do the trick.

Also, I see a problem with the salt: the client can never know it. It's too easy for a malicious attacker to disassemble your client and discover the salt.
You could use an asymmetric key, where the decryption key is known only by the server while the encryption key is public - but in my opinion, it's not worth the effort. That's why most [game] clients don't bother with login encryption

[Greg]

I start getting to the conclusion that making any securities is not worth of my effort, cause there's always some way to break it... xD