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

Question

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

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.

Comments

[buggedcom]

"implement a change" meaning convert my scripts to use bcrypt instead of the PBKDF2 algo.

[buggedcom]

I don't believe bcrypt is encryption. It's a one way hashing mechanism base on BLOWFISH

[Keith Palmer Jr.]

BCrypt is a hashing algorithm.

[David Murdoch]

-1. Bcrypt is for hashing, not encryption. You're answer hints that it is used for encryption (which is bad for storing passwords). I'll quickly reverse my vote if you clarify your opinions in such a way that readers will not be likely to assume that Bcrypt is used for encryption.

[m33lky]

"asking users of a website to type their password into an input box which only has space for 55 characters." I'm sorry, but how is this applicable to the real world? I can hardly come up with 8 character passwords.

[Cheeso]

I know a guy that uses sequences of great chess games as passwords. He salts the sequences with the names of the players, dates, cities played, etc. I know another person who uses verses from epic poems, with intentional errors introduced. There are plenty of ways to get rilly long passwords.

[ircmaxell]

It should be noted that there was an error in the scrypt paper, and the actual algorithmic cutoff of bcrypt is 72 characters. So there's still a cutoff, but it's got 128 more bits of entropy. Which is extremely significant.

[dchest]

@ircmaxell depends on implementations (and most do accept 72 bytes), but the effective key size of Blowfish is 448 bits; while it can accept up to 576 bits (72 bytes as you say), "last four values of the P-array don't affect every bit of the ciphertext" (quote from Wikipedia en.wikipedia.org/wiki/Blowfish_(cipher)#The_algorithm).

[2Toad]

@m33lky using password phrases instead of passwords is something being done in the real world. Password phrases can easily surpass 55 characters in length, and are often easier to remember then random numbers+characters+symbols (codinghorror.com/blog/2005/07/passwords-vs-pass-phrases.htm‌​l).

[Can H. Tartanoglu]

@2Toad you are right, but you forgot to mention that password phrases are also easier to hack than randomized chars assuming the lengths are approximately the same.