Not a General-Purpose Hash
Common hashing algorithms like SHA-256 are designed to be fast — a property that's excellent for verifying file integrity or building data structures, but actually a liability for password storage. Bcrypt was designed specifically to be slow on purpose, which sounds counterintuitive until you understand what it's defending against.
Why Slow Is a Security Feature Here
If an attacker obtains a database of password hashes, their next step is typically trying to guess the original passwords by hashing huge numbers of candidate passwords and comparing results. With a fast hash function, an attacker can attempt billions of guesses per second on modern hardware. Bcrypt's deliberate slowness means each guess costs meaningfully more computational time — turning a feasible billions-per-second attack into a dramatically slower, far less practical one.
The Cost Factor
Bcrypt's "work factor" or "cost factor" is a tunable parameter controlling exactly how slow the hashing is — each increment roughly doubles the computation time required. This lets bcrypt stay appropriately slow even as hardware gets faster over time, simply by increasing the cost factor, without needing a new algorithm.
Built-In Salting
Every bcrypt hash automatically includes a random salt, generated fresh each time a password is hashed. This means two users with the identical password end up with completely different hash values, which defeats precomputed lookup-table attacks (rainbow tables) that rely on shared, unsalted hashes across many accounts.
Why This Combination Matters
Deliberate slowness plus automatic salting is exactly the combination password storage needs — one blocks brute-force guessing at scale, the other blocks precomputed attacks. This is why bcrypt (and similar purpose-built algorithms like Argon2 and scrypt) remain the recommended choice for password storage specifically, even though faster general-purpose hashes exist for other uses.
A Practical Detail Worth Knowing
Bcrypt only processes the first 72 bytes of input — anything beyond that is silently ignored during hashing. In practice this rarely matters for typical passwords, but it's worth being aware of if you're working with unusually long passphrases, since two different long passwords sharing the same first 72 bytes would hash identically.
Ready to try bcrypt hashing yourself?
Open Bcrypt Hash Tool