Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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!

share|improve this question

migrated from crypto.stackexchange.com Sep 4 '12 at 15:29

This question came from our site for software developers, mathematicians and others interested in cryptography.

What is your goal? Do you want to let only people play who have a user account (i.e. a valid user name/password combination)? Also, how does the "login" relates to the rest of your session? –  Paŭlo Ebermann Sep 2 '12 at 11:03
Essentially, I would like to limit multiplayer server to people who have bought the game, and are therefore registered on the login-server. The rest of the session is simply a transfer of interactions with the world and other players ( coordinates, messages, etc ) sent from the server to the client. –  Erkling Sep 2 '12 at 11:13

2 Answers 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.

share|improve this answer
Thank you for your answer, is there anyway I can migrate my question to the Security site? I believe it will likely be of more use there than here, as well as this question possibly taking the room of another. –  Erkling Sep 3 '12 at 17:10
@Erkling, sure! Just click "flag" underneath your question and leave a comment asking that the question be migrated. The moderators will take care of it from there. –  D.W. Sep 3 '12 at 18:46

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.

share|improve this answer
Yes, I was planning on using a salt for the hash. I take this is basically a standard thing to do? :) –  Erkling Sep 3 '12 at 17:10

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.