Bcrypt Cost Factor Explained: Choosing the Right Work Factor

Bcrypt is a password hashing function designed in 1999 that is still a sound default today. Its distinguishing feature is a tunable cost factor — a single number that makes every hash exponentially slower. This post explains what that number does and how to choose it.

Why a fast hash is the wrong tool

General-purpose hashes like SHA-256 are built for speed. A modern GPU can compute billions of SHA-256 hashes per second, which is exactly what an attacker wants when guessing passwords against a leaked database.

Password hashing flips the goal: each guess should be expensive. Bcrypt achieves this by running an intentionally slow key setup (derived from the Blowfish cipher) many times over. The cost factor decides how many.

Anatomy of a bcrypt hash

A bcrypt hash is a 60-character string:

$2b$12$R9h/cIPz0gi.URNNX3kh2OPST9/PgBkqquzi.Ss7KIUgO2t0jWMUW

Segment	Value	Meaning
$2b$	version	Algorithm identifier. 2a, 2b, and 2y are all bcrypt; 2b is current.
12	cost	The work factor. Iterations = 2¹² = 4,096.
R9h/cIPz0gi.URNNX3kh2O	salt	22 characters, 128 bits of random salt.
PST9/PgBkqquzi.Ss7KIUgO2t0jWMUW	hash	31 characters, the 184-bit result.

Because the salt and cost are stored inside the string, verification needs nothing else. A verifier reads the cost and salt from the stored hash, re-hashes the candidate password with them, and compares. You never store the salt separately.

How cost scales

The cost is an exponent. Each increment doubles the work:

Cost	Iterations	Rough time on one modern CPU core
10	1,024	~60 ms
11	2,048	~120 ms
12	4,096	~250 ms
13	8,192	~500 ms
14	16,384	~1 s
15	32,768	~2 s

The exact numbers depend on hardware, but the doubling holds everywhere. Cost 10 was the common default for years; as of the mid-2020s, 12 is a sensible baseline and OWASP recommends at least 10.

You can feel this directly: generate a hash with the Bcrypt Tool at cost 10, then at cost 14, and watch the delay grow.

Choosing a value

The right cost is a budget decision, not a security constant. Ask: how long can a login take?

1. Measure hashing time on your actual production hardware, not a laptop.
2. Pick the highest cost that keeps a single hash under your latency budget — commonly 250–500 ms for interactive logins.
3. Account for load. If 50 users log in at the same second on a 4-core box, each core runs a dozen hashes back to back.

A hash that takes 300 ms to compute means an attacker with the same hardware manages about three guesses per second per core. Even with a large GPU cluster, bcrypt's memory access pattern keeps it far less parallel-friendly than SHA-family hashes.

Raising the cost later

Hardware gets faster, so a cost chosen in 2020 is weaker in 2026. Because the cost lives in the hash string, upgrading is straightforward:

1. Change the cost used for new hashes.
2. On each successful login, check whether the stored hash uses the old cost. If so, re-hash the (now verified) plaintext with the new cost and save it.

Passwords get upgraded gradually as users log in, with no forced reset.

Limits worth knowing

• 72-byte input cap. Bcrypt only looks at the first 72 bytes of the password. Longer input is silently truncated. Some systems pre-hash with SHA-256 to work around this, but doing so carelessly introduces its own problems; if you need long passphrases, consider Argon2id instead.
• Not memory-hard. Bcrypt uses a fixed 4 KB of state. Argon2id and scrypt let you demand large amounts of memory, which hurts GPU and ASIC attackers more. Bcrypt remains acceptable; it is simply no longer the strongest option.
• Never use it for anything but passwords. Slowness is the point. For checksums, cache keys, or signatures, use SHA-256 or an HMAC — see the Hash Generator for the fast alternatives.

Summary

• The cost factor is an exponent; each +1 doubles hashing time.
• Salt and cost are embedded in the 60-character hash, so verification is self-contained.
• Start around cost 12, measure on production hardware, and revisit every few years.
• Upgrade old hashes lazily on login rather than forcing resets.