2

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

batfastad
  • 1,943
  • 3
  • 27
  • 37
  • `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 Sep 17 '12 at 23:29
  • Also see Openwall's [PHP password hashing framework](http://www.openwall.com/phpass/) (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](http://www.openwall.com/john/) and sits as a judge in the [Password Hashing Competition](http://password-hashing.net/). So he knows a thing or two about attacks on passwords. – jww Oct 12 '14 at 01:55

2 Answers2

5

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

Kenny Grant
  • 9,360
  • 2
  • 33
  • 47
  • Nice one on the forward compatible port! I think it will be a while before I start seeing hosting environments running PHP 5.5. I found http://openwall.com/phpass/ but I'm not sure how well maintained it is or will be in the future. – batfastad Sep 17 '12 at 23:04
2

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.

Community
  • 1
  • 1
donutdan4114
  • 1,262
  • 1
  • 8
  • 16
  • Yeah if your system is fully hacked then the pepper is pointless. But if someone just manages to dump your database then it offers some protection. Though if someone only manages to dump my database then there's probably an SQL injection vulnerability somewhere and I've not done my job properly in the first place. It was easy for me to implement a pepper, so I thought I may as well do so. – batfastad Sep 18 '12 at 09:15
  • Yea, certainly more protections are better than less protections. It's just always good to ask, "Is my security dependent on obscurity?" You're system does not *rely* on the pepper so it is not a downside. Use bcrypt and you'll be more secure than 99% of sites out there... (which is a sad fact btw) – donutdan4114 Sep 18 '12 at 23:12