On the surface bcrypt, an 11 year old security algorithm designed for hashing passwords by Niels Provos and David Mazieres, which is based of initialization function used in the NIST approved blowfish algorithm seems almost to good to be true. It is not vulnerable to rainbow tables (since creating them is too expensive) and not even vulnerable to brute force attacks.

However 11 years later, many are still using SHA2x with salt for storing password hashes and bcrypt is not widely adopted.

  • What is the NIST recommendation with regards to bcrypt (and password hashing in general)?
  • What do prominent security experts (such as Arjen Lenstra and so on) say about using bcrypt for password hashing?

bcrypt has a significant advantage over a simply salted SHA-256 hash: bcrypt uses a modified key setup algorithm which is timely quite expensive. This is called key strengthening, and makes a password more secure against brute force attacks, since the attacker now needs a lot more time to test each possible key.

In the blog post called "Enough With The Rainbow Tables: What You Need To Know About Secure Password Schemes", which I personally recommend you to read, Thomas Ptacek, the author and a security researcher recommends the usage of bcrypt.

Personally, I've been looking at PBKDF2 lately, which is a key derivation function that applies a pseudo-random function (e.g. cryptographic hash) to the input password along with a salt, and then derives a key by repeating the process as many times as specified. Although it's a key derivation function, it uses the principle of key strengthening at its core, which is one of many things you should strive for when deciding on how to securely generate a hash of a password.

To quote Thomas Ptacek from the above linked post:

Speed is exactly what you don?t want in a password hash function.


bcrypt uses blowfish as a message digest function. Blowfish is very old and has been replaced by twofish, thus bcrypt should not be used on a modern system.

As an accomplished cryptographer I recommend using a salted sha256. Sha256 is one of the NIST recommended message digest functions and should be used until until sha3 is finalized. (Skien for the win!)


I think Gui's suggestion about PBKDF2 has merit, although I know Rook disagrees strongly. If only they were clear about their reasoning!

Regardless, there's no reason to use a salted SHA-256 hash in comparison to HMAC-SHA256. HMAC has the advantage of blocking extension attacks.