Passwords storage, hash() with sha-512 or crypt() with blowfish (bcrypt)?

2
votes

This is my current password hashing procedure in PHP/SQL projects...

  • Take 512bits of per-user salt from /dev/urandom, stored in the user's DB record in addition to the final hash
  • Take 512bits of "pepper" from /dev/urandom which is stored in the file system. This is a constant per-application and is the same for each user
  • Then hash('sha512', $password.$salt.$pepper, TRUE)

The hash and salt are stored in binary in the DB, mainly out of habit. I don't think it makes any difference in terms of security. If anything it's slightly less convenient for SQL backups and makes the PHP code appear marginally more complex.

Is hash() with SHA-256 or SHA-512 generally considered to have been superceeded by bcrypt these days?
I believe SHA-2 (256/512) is still considered cryptographically secure and I'm probably overdoing the entropy bits. It's far more likely that it would be a flaw in my code that would lead to problems than an attacker reverse-engineering a SHA-2 hash from a DB dump.

But should I update my methodology going forward to use crypt() with CRYPT_BLOWFISH instead (I believe this is referred to as bcrypt, with blowfish technically being a cipher rather than hashing algorithm)?
Even just as future best practice?

I'm not particularly concerned about the computational expense of the algorithms (within reason). This would only ever be a factor when creating accounts, changing passwords or on login when you hash then compare. Those activities make up a small percentage of page views. I guess in a way the slower the better, if it makes a server work harder to generate then it will make an attacker's work slower to brute force.

Cheers, B

2
phphashshabcryptpassword-encryption
I guess in a way the slower the better, if it makes a server work harder to generate then it will make an attacker's work slower to brute force. This is absolutely true, and a big feature of recommended hashing strategies is the ability to tweak (increase) the expense of the hash (without invalidating stored hashes) as hardware advances reduce the relative cost of hashing. crypt with Blowfish offers this. – grossvogel
Also see Openwall's PHP password hashing framework (PHPass). Its portable and hardened against a number of common attacks on user passwords. The guy who wrote the framework (SolarDesigner) is the same guy who wrote John The Ripper and sits as a judge in the Password Hashing Competition. So he knows a thing or two about attacks on passwords. – jww

2 Answers

5
votes

If you can wait til php 5.5, there will be some helpful functions for this built in:

https://gist.github.com/3707231

Till then, use crypt - you could look at this forward compatible port of the new functions:

https://github.com/ircmaxell/password_compat

2
votes

You are definitely on the right track, bcrypt is a very nice way to store your passwords (scrypt is better but hard to find a good implementation in PHP).

Remember that sha1, sha256, sha512 were never made to hash passwords. They were designed to be fast, so that you could take large data sets and create a unique signature for them, in the shortest amount of time. They are used for signing more than anything else.

You definitely want to use a hashing algorithm that takes more time.

Side note: Some would argue that the pepper is pointless, since if they hack your system, they will have access to your salts and pepper.

This post has some great insights into password security.