Password Hashing: PBKDF2 (using sha512 x 1000) vs Bcrypt

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?


Solution 1:

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:

Estimated cost of hardware to crack a password in 1 year.

Iteration counts for PBKDF2-HMAC-SHA256 used there are 86,000 and 4,300,000.