Why Password Hashing Needs to Be Slow On Purpose

Speed is usually a feature. For password storage, it's a liability

For almost every use of a hash function — checking file integrity, generating a cache key — faster is better. Password storage is the one major exception, and understanding why reveals a lot about how real-world password attacks actually work.

How attackers actually crack stolen password hashes

When a database of hashed passwords leaks, attackers don't try to mathematically "reverse" the hash — that's not feasible for a well-designed hash function. Instead, they guess likely passwords, hash each guess, and check whether it matches a hash in the stolen data, trying billions of common passwords, previously leaked passwords, and pattern-based variations. The speed of this attack is limited entirely by how fast the attacker can compute the same hash function the original system used.

Why that makes fast hashes dangerous for passwords

A general-purpose hash like SHA-256 is deliberately built for speed, since it's also used for things like verifying large file downloads, where you want the calculation to finish instantly. That same speed lets modern hardware compute billions of SHA-256 hashes per second, meaning an attacker with a stolen SHA-256 password database can test enormous numbers of guesses very quickly.

Bcrypt's deliberate slowness

Bcrypt was specifically designed to be slow, and adjustably so, through its "cost factor." Each increase of one in the cost factor roughly doubles how long a single hash takes to compute — not a side effect, but the entire security mechanism. If checking one password guess takes even a tenth of a second instead of a billionth, an attacker's guessing rate drops by many orders of magnitude, making large-scale guessing attacks against a stolen bcrypt database dramatically less practical.

Salting: the other essential piece

Bcrypt also automatically generates a random "salt" for every password it hashes, which is mixed into the calculation. This is why hashing the identical password twice produces two different-looking bcrypt outputs, and it defeats "rainbow table" attacks — precomputed lookup tables of common password hashes — since an attacker would need a separate precomputed table for every possible salt value, which isn't practically feasible.

Try it yourself

Our Bcrypt Hash Generator lets you generate a real bcrypt hash with an adjustable cost factor (you'll notice higher settings genuinely take longer to compute — that's the security working as intended), and includes a verify mode to check text against an existing hash.