Menu
I've been reading about the Gawker incident and several articles have cropped up regarding only using bcrypt to hash passwords and I want to make sure my hashing mechanism is secure enough to avoid switching to another method. In my current application I have opted for a PBKDF2 implementation utilising sha2-512 and a minimum of 1000 iterations.
Can I ask for opinions on using PBKDF2 vs Bcrypt and whether or not I should implement a change?
727
SHA-512 has been designed to be fast. You don't want any delays when validating a signature, for instance. There is no reason for generic cryptographic hashes to be slow. bcrypt on the other hand is a password hash that performs key strengthening on the input.
Yes, all other things being equal, you should prefer bcrypt, which forces more effort onto attackers than PBKDF2 given similar parameters. The reality is, bcrypt, scrypt, PBKDF2: throw a dart at them and you'll be fine no matter which you hit.
To protect passwords, experts suggest using a strong and slow hashing algorithm like Argon2 or Bcrypt, combined with salt (or even better, with salt and pepper). (Basically, avoid faster algorithms for this usage.) To verify file signatures and certificates, SHA-256 is among your best hashing algorithm choices.
TL;DR; SHA1, SHA256, and SHA512 are all fast hashes and are bad for passwords. SCRYPT and BCRYPT are both a slow hash and are good for passwords. Always use slow hashes, never fast hashes.
As of 2022, it's best to switch to a memory-hard function, such as scrypt or Argon2. Bcrypt could also be an option, but it's not memory-hard.
As for PBKDF2, the recommendation to use 1000 iterations was made in year 2000, now you'd want much more.
Also, you should take more care when using bcrypt:
It is also worth noting that while bcrypt is stronger than PBKDF2 for most types of passwords, it falls behind for long passphrases; this results from bcrypt’s inability to use more than the first 55 characters of a passphrase While our estimated costs and NIST’s . estimates of passphrase entropy suggest that bcrypt’s 55-character limitation is not likely to cause problems at the present time, implementors of systems which rely on bcrypt might be well-advised to either work around this limitation (e.g., by “prehashing” a passphrase to make it fit into the 55-character limit) or to take steps to prevent users from placing too much password entropy in the 56th and subsequent characters (e.g., by asking users of a website to type their password into an input box which only has space for 55 characters).
From scrypt paper [PDF]
That said, there's also scrypt.
Any comparisons would be incomplete without the table from the scrypt paper mentioned above:
Iteration counts for PBKDF2-HMAC-SHA256 used there are 86,000 and 4,300,000.
91
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
