views:

25

answers:

1

Any comments/improvements on this process?

User Table: id, username, password, salt

Storing a New User

  1. Receive the username (plaintext) from $_POST
  2. Receive the password (sha512'd using javascript) http://pajhome.org.uk/crypt/md5/sha512.html from $_POST
  3. Generate a 128 character salt (alphanumeric with symbols) on the server and store it in the salt column
  4. Prepend the password hash with the salt and save it in the password column
+2  A: 

Yes. A few things:

  • It's pointless to hash the data client-side with Javascript. Use https to transmit the data instead.
  • The point of salt is to thwart rainbow table attacks, where the attacker has precomputed the hashes of a big number of strings in order to find a reverse correspondence from hash to original string. It's pointless to prepend the salt to the hashed password, because the attacker can simply strip the salt.

The correct way is this:

  1. Send the password to the server only encrypted via https (no Javascript)
  2. Generate a long, random salt – use a good random generator (not PHP's rand...)
  3. Append the password to the salt
  4. Store a hash of the salt+password, together with the salt.

Then, to authenticate:

  1. Send the password to the server only encrypted via https
  2. Get the salt from the DB
  3. Append the password to the salt
  4. Compute the hash of the salt+password and compare with what you have in the DB
Artefacto
How long of a salt? (number of chars). How quick should the authentication process be if you have 1,000,000+ users? (under 30 ms?)
Kirk
@Kirk It's not so much about the length as to the entropy. If you use only letters, you'll need a bigger salt. I don't know if there's an industry standard for this, but a 16 character salt with only good random numbers and letters should be enough. As to your second question, it's impossible to answer. If there's a requirement on the latency, you should satisfy it, if not, it's arbitrary...
Artefacto