Security · 4 min read
bcrypt Explained: How to Store Passwords Safely
If your application stores passwords, it should never store the passwords themselves — only a hash that can verify them. But not any hash will do. bcrypt has been the safe, boring choice for over two decades, and understanding why makes the rest of password storage click.
Try it yourself with the related tool.
Generate or verify a bcrypt hash →Advertisement
Why a fast hash is the wrong tool
SHA-256 is designed to be fast, and that is exactly the problem. When a database leaks, attackers hash billions of guesses per second on GPUs and compare them to the stolen hashes. bcrypt is deliberately slow and tunable, so each guess costs real time — turning hours of cracking into years.
Reading a bcrypt hash
A bcrypt hash looks like $2b$12$ followed by 53 characters. 2b is the algorithm version, 12 is the cost factor, the next 22 characters are the random salt, and the remaining 31 are the hash itself. Because the salt and cost are stored inside the string, you only ever keep one column in the database.
The salt means two users with the same password get completely different hashes, which defeats precomputed rainbow tables.
Choosing the cost factor
The cost is a power of two: each step up doubles the work. Pick the highest value that keeps a login check around 100–300 milliseconds on your server — today that is usually 10 to 12. Because the cost is recorded in each hash, you can raise it later and rehash users transparently the next time they sign in.
Limits and alternatives
bcrypt only uses the first 72 bytes of input, so very long passphrases are silently truncated. Argon2id is the newer recommendation and also resists memory-heavy GPU attacks, but bcrypt remains perfectly acceptable. Whatever you choose, always compare hashes with the library's verify function rather than string equality.