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
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