What Is a bcrypt Cost Factor, and What Should Yours Be?

A bcrypt hash looks like $2b$10$N9qo8uLOickgx2ZMRZoMye... — three dollar-sign-separated fields most people ignore past the first one. That middle number, the cost factor, is the entire point of using bcrypt instead of a fast hash like SHA-256: it's a dial that deliberately makes hashing slow, and picking the wrong number either wastes CPU or leaves passwords crackable.

Why slow is the feature, not a bug

A fast hash function is bad for passwords precisely because it's fast — an attacker with a stolen hash database can try billions of guesses per second on commodity GPUs. bcrypt's cost factor sets the number of key-derivation rounds as 2^cost, so cost 10 means 1,024 rounds and cost 14 means 16,384. Each increment doubles the work for both you and the attacker, but you only pay that cost once per login, while the attacker pays it per guess across billions of guesses.

What each cost factor actually costs in latency

• Cost 8–9 — a few milliseconds per hash. Fine for local dev, too weak for anything real.
• Cost 10 — roughly 12ms per hash on typical server hardware. The widely-used default, and a reasonable floor.
• Cost 12 — roughly 48ms. A meaningful security bump if your login endpoint can absorb the extra latency.
• Cost 14 — roughly 200ms per hash. Only worth it for genuinely high-value targets — this adds real, user-visible delay to every login.

The jump from 10 to 14 isn't linear — it's 16x more compute per hash, which is exactly the point: it should hurt an attacker running millions of attempts far more than it hurts your one legitimate login per user.

How to actually pick a number

1. Start at 10 unless you have a specific reason not to — it's the tested default across most bcrypt implementations for a reason.
2. Move to 12 if you're hashing anything more sensitive than a low-stakes account and can tolerate ~50ms of added login latency.
3. Only go to 13–14 if you've benchmarked your actual server hardware and confirmed the latency is acceptable at your login volume — this is not a "more is always better" setting once user experience is in the equation.
4. Re-hash on login, not in bulk, when you eventually raise the cost factor — bcrypt hashes don't need to be migrated all at once; just re-hash each user's password the next time they log in successfully.

Try it

The bcrypt Generator hashes and verifies passwords entirely in your browser, with a visual breakdown of a hash's algorithm version, cost factor, salt, and checksum — and shows the actual computed time at each cost level, so you can pick a number based on real numbers instead of a guess.