Is this login authentication safe?

Question

I have been thinking of a way to authenticate users so as to pick out the users using cracked versions of my game from the people who have actually bought it. I came up with this idea:

The client asks the login-server for his bl_hash, which is updated every 12 hours. (Does it need to be a smaller time frame? I am using Threefish-512 to update the blocks, the key would be a CSPRNG's output. )

The client then encrypts the bl_hash with the hash of his password (the u_hash), this is known as the l_hash.

The client sends his l_hash to the gameserver along with his username. This is packet_login.

The game-server sends the received packet_login data to the login-server.

The login server decrypts the l_hash with the u_hash and replies to the server whether this is the guy who he says he is or not.

The game-server either rejects or accepts the player according to what is received from the login server.

I understand this could be susceptible to a man-in-the-middle attack for the server, but this would probably be impossible to do since the gameservers will likely be inside a data centre. Are there any possible improvement that I can make?

Thank you for your time, and I deeply apologise if this is in the wrong site!

Answer 1

If I understand you correctly, the login packet will be exactly the same for the same user within the validity time of bl_hash. So a passive attacker can record and replay it. To prevent this kind of attack, bl_hash should be used only once (see nonce).

Decrypting the login packet with the hash of the user password, implies that the hash is not salted. A salt is a random string that is unique for each password and is concatenated before the hash is calculated. It prevents an attacker, who got access to the account database, to attack all passwords in parallel with a dictionary attack. Instead of a simple hash, you should use one of the password hashing algorithms such as sha512crypt, bcrypt or scrypt to store the password.

The client does not authenticate the server. Therefore a man in the middle attack is possible.

I strongly recommend to use SSL. It is a very well tested protocol with libraries for all common programming languages. And it is not vulnerable to any of these problems.

Answer 2

This isn't primarily a cryptography question; it is primarily a question about risk management. No solution will provide ironclad security. Instead, you need to identify the leading risks (the leading ways that users will try to defraud you), and then put in place controls or mitigations that reduce the risk to an acceptable level. Most of those controls are likely to be non-cryptographic in nature.

(For this reason, I think you'd get better answers on the IT Security site.)

Some sample mitigations:

• Use SSL when logging in.

• Record the client's IP address. Check their geographic region. Flag any accounts that appear to shift geographic regions in a suspicious manner.

• Record details about the client's platform (e.g., operating system, version numbers, network MAC address). Flag any account where these seem to change in a suspicious manner.

• Detect the language used in online chat by this user (e.g., English, Russian, German, etc.). If it changes in a suspicious manner, flag the account for further scrutiny by a human.

• Implement defenses against "cracks" of your game binary. There's a lot written on this topic; you can search the Internet.

You'll have to decide which ones have a suitable cost/benefit tradeoff.