-2

I'm creating an login system in php. I have a custom table for e-mail check, which gets the user register data, and then move it to the table user.

I would like to know if it's safe to create the random salt and store it with hashed password on temporary user table, or it's better to store only normal password them hash it and create salt after the user confirmation?

I was thinking that an user could some how make a mass "register" with various e-mail address (which can't be real validate) and slow down the server (because of the salt and hash create functions). By the way, creating the hash after leads to a non trigger (I'm using MySQL) situation, because some of the values must the added (created) manually.

Funk Forty Niner
  • 74,450
  • 15
  • 68
  • 141
Renato Probst
  • 5,914
  • 2
  • 42
  • 45
  • Please edit your question, do **NOT** use `code` syntax when there is no code at all! – Matteo Tassinari Oct 14 '13 at 14:55
  • Some tips on passwords: http://stackoverflow.com/a/401684/2271198 – Marcos Oct 14 '13 at 14:59
  • I think you are down voting cause you misunderstood the nature of the question. Just read the third paragraph, its not a "tell me the code" question. – Renato Probst Oct 14 '13 at 15:29
  • possible duplicate of [Secure hash and salt for PHP passwords](http://stackoverflow.com/questions/401656/secure-hash-and-salt-for-php-passwords) – Peter O. Oct 14 '13 at 17:31

2 Answers2

1

You could generate a long random salt, prepend the salt to the password and hash it with a standard cryptographic hash function such as SHA256. Then save both the salt and the hash in the user's database record. NEVER store a plaintext password!

When you want to validate the user's login, all you need to do is retrieve the user's salt and hash from the database, prepend the salt to the given password and hash it using the same hash function. Then compare the hash of the given password with the hash from the database. If they match, the password is correct. Otherwise, the password is incorrect.

Do NOT:

  • Use outdated hash functions like MD5 or SHA1
  • Use insecure versions of crypt ($1$, $2$, $2a$, $2x$, $3$)
  • Use any algorithm that you designed yourself. Only use technology that is in the public domain and has been well-tested by experienced cryptographers

More Information

Winter
  • 1,699
  • 1
  • 19
  • 26
  • Thank you Winter, but i know all that, what i want to know is if its safe to store the random salt and hashed passw direct on the temp_user, or only after the user confirmate (by e-mail) its account ? – Renato Probst Oct 14 '13 at 15:14
  • Store it hashed on the temporary user, but deny login until the account is confirmed. At least, I think that's what you're trying to do.. – Winter Oct 14 '13 at 17:52
1

If you are really concerned about a server slow-down, then simply wait until the user clicks on the confirmation link. Then let the user choose his own password and store its hash. This way you can avoid the salt and hash generation completely (for fake accounts) and have the advantage that you do not have to generate a machine password.

What you should not do is, to store a password-hash without a good salt. If you read from DEV_URANDOM (do not use DEV_RANDOM), then your server should have no problem with blocking and should not slow down because of the salt generation.

Keep in mind, that there are other ways to slow down your server, an attacker could for example use the login form to provoke hash calculations.

By the way, with an appropriate function like password_hash() there is no reason to generate the salt on your own, this function will do its best to generate a safe salt, and it will use a slow key-derivation function (BCrypt) which should be used for passwords (not SHA-* or even MD5).

martinstoeckli
  • 23,430
  • 6
  • 56
  • 87