We help IT Professionals succeed at work.

Is Bcrypt the right hashing algorithm to use for passwords?

Hi there,
I've read many articles about hashing algorithms.  Their pros, their cons etc.

I think I have decided upon using the brcypt algorithm to hash my passwords with a unique per user salt.

The main reasons that I like it are :
  • It's been out for a long time and as far as I'm aware there are no known issues with it.
  • It was designed to be used for passwords and even includes 'salt' as a parameter.
  • It is relatively slow (compared to other hashing algorithms) to create a hash thereby hindering brute force attacks and someone creating lookup and rainbow tables of passwords with the salt combined.

My only concern is that it has been out for a long time now.  Should I still use it or should I move on to a new algorithm like Argon2, scrypt, SHA3 etc

Does anyone with better knowledge than myself have any insights as to whether I'm ok sticking with my Bcrypt decision or whether I should move on to a newer algorithm?

Watch Question

Software Developer
Again OWASP has the info you need:


Their top list (currently):

1. Argon2[*7] when it becomes available. Argon2 is the winner of the password hashing competition and should be considered as your first choice when solid implementations are available.
2. PBKDF2 [*4] when FIPS certification or enterprise support on many platforms is required;
3. scrypt [*5] where resisting any/all hardware accelerated attacks is necessary but support isn’t.
4. bcrypt where PBKDF2 or scrypt support is not available.

Simply have the full read about this and you don't need to ask further questions here.

Bye, Olaf.
btanExec Consultant
Distinguished Expert 2019
PKCS#5 will stay like mentioned in PBKDF2 - You probably has seen also NIST SP 800-132 recommends using PBKDF2 for password hashing. The likely change is just the hash algorithm used. In fact, PBKDF2 is used as an algorithm for generating a cryptographic key from a password, not specifically for hashing a password for safe storage for authentication purposes.  This does not mean that NIST is seeing bcrypt as insecure but more of PBKDF is secure for such hashing purpose cases. Most will go for this NIST for compliance (lesser explanation since it comes from a standard body).

Bcrypt is also another password hashing function and it is know to be slow with deter for those "impatient" attacker - it is heavily rely on accesses to a table which is constantly altered throughout the algorithm execution. Speed is what a password hash function should have considered. Real time light weight platform (IoT) adopting hashing function will requires some dedicated crypto hardware to save the computing cost which a PC can invest in to run the hashing. In this case, Bcrypt can be disadvantage but it is still secure as-is.

Actually, Bcrypt is an algorithm that uses Blowfish internally. It is not an encryption algorithm itself.  It still has an irreversible algorithm to obscure the password but strictly speaking it is not looked into as the list of hashing family. Most has gone for and also scrutinised the SHA2 family, so it is still the safe guideline though SHA3 exists - there is lead time to gain traction as mentioned. I still see SHA2 as more widely used as the secure hash though most is still in the midst to transit app to support SHA2.

Ultimately the pass hashing is to obscure and deter the brute force attempt which Bcrypt can still do so but probably the acceptance for compliance may still as on SHA2 family which PKCS#5 scheme covers. But if I will to compare Bcrypt, it should be leveled up with SHA 512 instead. See this test btw SHA512 and Bcrypt
Personally, while I like the ideas of bcrypt and scrypt, I would recommend sticking with the NIST recommendations with high iteration counts, as shown above. Until we see more standards boy interest in bcrypt and scrypt, IMO, you are taking a risk using them for password storage (less so for bcrypt than scrypt at least).

I'll tell you to use either PBKDF2 or SHA-2 with high iterative counts. Or, if you must absolutely use bcrypt, then I'll recommend that you use scrypt instead.