0

This is somewhat a followup to "About password_hash() in PHP and storing (part of) its salt outside DB".

Is there a way or any advantage to have a system-wide salt and a user-specific salt vs just a user specific salt? If so, how can I archieve that with that function? Is there a way to replace its internal salt generator with something as secure or more secure than it and then only store the user portion of the salt in the user table?

If the system salt is used, it will be stored in a different place in a specific server.

  • Feeding password_hash() an MAC of the password is easier. See hash_hmac(). The key you feed into hash_hmac would be your 'system-wide salt'. – Darsstar Dec 12 '14 at 20:15
  • @Darsstar So... something somewhat like this? $store = password_hash(hash_hmac('sha512', $password, $sysSalt), PASSWORD_BCRYPT) – brunoais Dec 13 '14 at 10:04
  • That would work. But you might want to have hash_hmac() return the raw output. Just remember null bytes since bcrypt expects a null terminated string. – Darsstar Dec 14 '14 at 9:09
  • @Darsstar, @brunoais: Do NOT do pass password_hash the output of hash_hmac, as explained at: blog.ircmaxell.com/2015/03/… This is a security concern as it increases the likelihood of password collisions because hash_hmac can return null bytes, and password_hash stops hashing after the first null byte it encounters. – 0xdabbad00 Mar 12 '15 at 20:08
  • @0xdabbad00 I did mention null bytes and how bcrypt expects a null terminated string, didn't I? One can filter them out for example... – Darsstar Mar 12 '15 at 22:08
2

That's called a "keyed hash" and the key is sometimes called "pepper."

Yes, there is a security advantage. If the key is not stored in a database but is, perhaps, a constant in a program, then a database leak through SQL injection or similar will not reveal the key and your data will be nearly crack-proof.

Of course, if the OS gets owned, it sort-of doesn't make any difference what you've done. However, it at least appears that many password leaks are due to SQL injection attacks.

There is an extremely useful essay on password hashing here: https://crackstation.net/hashing-security.htm It has a section on keyed hashes. That essay recommends against hard-coding the key, and that's right if you're going to install a program in a number of places. For a one-off installation, I still think it's OK. Just be sure that the key is generated using a cryptographically secure random number generator (CSPRNG) in any case.

  • Hum... I better ask in stackoverflow about how to use that with password_hash(). Thanks for the information! – brunoais Dec 13 '14 at 9:51
  • I'm no cryptographer, but I think you compute an HMAC with password and secret key, then pass the HMAC to the password hashing function as the "password." I do know you can't just concatenate password and key; there's an attack against that. – Bob Brown Dec 17 '14 at 20:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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