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 am currently developing a game which will be run in a client, they will sign up for this game online and create their account there, their information will be stored into a MySQL database. I am creating the game using Lua + Love2D, upon launch of the game the user will be presented with a login and password field. The process will go as follows:

  1. User submits their data
  2. Client sends their username to the server requesting their password salt
  3. Client receives salt from server and appends it to their input
  4. Client hashes appended password a certain amount of times using SHA256
  5. Client sends final hash to server
  6. Server checks it's the correct hash
  7. Client receives 'true' or 'false' depending if it's the correct password

Now my question is, I hear that someone can easily intercept this data, and get their username, salt, and password hash, then basically send this information to the server somehow getting them authentication to that persons accounts. How can I prevent this from happening? Can I use something like an authentication key? If so, can you explain how that would work?

share|improve this question

1 Answer 1

up vote 0 down vote accepted

Yes you are right, someone could intercept the communications and log in as the user, also you are doing a lot of extra unnecessary work on the client. Here is the steps I would do

  1. User submits their data
  2. Client establishes a secure link to the server (SSL or similar)
  3. Client sends their username and password over the secure link to the server.
  4. The server looks up the username in the database and retrieves the salt, the iteration count, and the hashed password
  5. The server runs the sent password, the looked up salt, and the looked up iteration count through a proper password derivation function like bcrypt or pbkdf2
  6. The server compares the output of the previous function to the hashed password it looked up
    1. (optional) If the password was correct, the server checks to see if you have raised the minimum iteration count for the server, if the user's account is below the minimum the server will run the password through again at the new iteration count level with a new salt and record the new hash, the new count, and the new salt in the database.
  7. Client receives 'true' or 'false' over the secure link depending if it's the correct password
share|improve this answer
    
Are you sure it's safe to send their plain password over secure link? And if their information is intercepted would they be able to decrypt the encrypted information in the secure link? –  Bicentric Nov 15 '13 at 0:20
    
That is the point of the secure link, if you use something like SSL correctly (checking that the cert you receive from the server is the cert you expected to see) it can't be intercepted. –  Scott Chamberlain Nov 15 '13 at 1:05
    
Ahh okay! I will do a lot of research on SSL, and try to set something up! Thank you very much! –  Bicentric Nov 15 '13 at 1:14

Your Answer

 
discard

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

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