Storing passwords securely is one of the most important responsibilities of any application that handles user authentication. A database breach that exposes passwords is a major incident. Using bcrypt to hash passwords before storing them ensures that even if your database is compromised, an attacker cannot easily recover the original passwords.
Why Fast Hashes Are Wrong for Passwords
MD5 and SHA-256 are fast hash functions. They were designed to be fast so that hashing large amounts of data (files, messages) is efficient. This speed is a security liability for password hashing. A modern graphics card can compute billions of SHA-256 hashes per second. An attacker with a database of password hashes and a GPU can try billions of guesses per second until they find a match.
What Makes Bcrypt Secure
Bcrypt was designed specifically for password hashing. Its key features are:
A cost factor (also called work factor or rounds). The bcrypt algorithm is intentionally slow, and the cost factor controls how slow. A cost of 12 means the algorithm performs 2 to the power of 12 (4096) iterations internally. Increasing the cost by 1 doubles the computation time. You can increase the cost as hardware gets faster to keep pace with attackers.
A built-in salt. A salt is a random value added to the password before hashing. Bcrypt generates a fresh random salt for every password hash, which means two users with the same password will have different hashes. This prevents precomputed rainbow table attacks.
Resistance to GPU acceleration. The bcrypt algorithm was designed to resist efficient parallelisation on GPUs, the hardware attackers use for large-scale cracking.
Choosing the Right Cost Factor
The current recommended minimum cost factor is 12. This produces a hash that takes approximately 250 milliseconds to compute on typical server hardware. That is negligible during a login operation but makes brute-force attacks impractical (at 4 million hashes per second you can check 86 billion guesses per day; at 250 ms per hash you can check only a few hundred per second).
As hardware improves over years, increase the cost factor to maintain the same computation time.
Using the DevHexLab Bcrypt Generator
Open the tool at /tools/security/bcrypt-generator. Enter the password, set the cost factor, and click Hash. The tool produces a bcrypt hash string that you can store in your database. Use the Verify tab to confirm that a plain-text password matches a stored hash.
Frequently Asked Questions
Do I need to store the salt separately?
No. The bcrypt hash string includes the cost factor and the salt as its first parts. The hash string you store in the database is everything you need to verify future logins.
Should I use bcrypt, Argon2, or PBKDF2?
All three are acceptable for password hashing. Argon2 (the winner of the 2015 Password Hashing Competition) is theoretically superior and is the recommended choice for new applications. Bcrypt is battle-tested and has excellent library support in every language. PBKDF2 is acceptable but less hardened against GPU attacks than the other two.
Use a slow hash function for passwords. Never use MD5, SHA-1, or SHA-256 alone for password storage.