bcrypt: Cost vs Hashing Time
bcrypt is a password-hashing function designed by Niels Provos and David Mazières in 1999, built on the Blowfish cipher. Unlike MD5 or SHA-256, bcrypt is intentionally slow: its cost factor (also called the work factor) controls exactly how slow it is. The cost is an exponent of 2, so cost=12 means bcrypt performs 2¹² = 4,096 internal key-expansion rounds. On a modern server CPU, cost=12 takes ~100 ms per hash—fast enough for user logins, slow enough to make brute-force attacks economically prohibitive. This calculator shows you the hashing time, approximate throughput (hashes/second), and whether your chosen cost is secure for 2025–2026 hardware.
When to use this calculator
- Setting a secure bcrypt cost factor for a new web application's user authentication system, ensuring logins take ~100–300 ms without degrading UX.
- Auditing legacy apps using cost=8 or cost=10 (now considered insufficient) and calculating the migration effort to rehash all stored passwords at cost=12+.
- Capacity planning for a high-traffic login endpoint: estimating how many concurrent bcrypt verifications a server can handle before CPU becomes the bottleneck.
- Estimating attacker cracking speed on commodity GPU hardware (e.g., an RTX 4090 does ~184,000 MD5/s but only ~184 bcrypt/s at cost=12), to quantify the security margin of your chosen cost.
Example calculation
- cost=12
- ~100 ms
How it works
3 min readHow It's Calculated
bcrypt's cost factor is a base-2 exponent applied to the number of key-schedule iterations inside the Blowfish cipher. The wall-clock time scales exponentially:
Time(cost) = T_ref × 2^(cost − cost_ref)
Where:
T_ref = measured time (seconds) at a known reference cost on your hardware
cost_ref = the reference cost factor used to establish T_ref
cost = the target cost factor you want to evaluate
Example (commodity server CPU, 2024):
T_ref = 0.012 s at cost_ref = 10
Time(12) = 0.012 × 2^(12−10) = 0.012 × 4 = 0.048 s ≈ 48 ms
Time(14) = 0.012 × 2^(14−10) = 0.012 × 16 = 0.192 s ≈ 192 ms
Hashes per second:
hashes_per_sec = 1 / Time(cost)> Note: bcrypt is memory-hard in the sense that it requires ~4 KB of RAM per hash (the Blowfish P-array + S-boxes), which severely limits GPU parallelism compared to pure compute-bound hashes like MD5.
---
Reference Table
Benchmarks collected from open-source projects (hashcat, john-the-ripper) and OWASP guidance. CPU column = single core of a modern server (e.g., AMD EPYC 7763); GPU = NVIDIA RTX 4090.
| Cost | Rounds (2^cost) | Time/hash (CPU) | CPU hashes/s | GPU hashes/s (RTX 4090) | Security rating (2025) |
|---|---|---|---|---|---|
| 8 | 256 | ~0.8 ms | ~1,250 | ~350,000 | ❌ Insecure |
| 10 | 1,024 | ~12 ms | ~83 | ~21,000 | ⚠️ Marginal |
| 11 | 2,048 | ~25 ms | ~40 | ~10,500 | ⚠️ Marginal |
| 12 | 4,096 | ~100 ms | ~10 | ~5,250 | ✅ Recommended (2025) |
| 13 | 8,192 | ~200 ms | ~5 | ~2,625 | ✅ Strong |
| 14 | 16,384 | ~400 ms | ~2.5 | ~1,312 | ✅ Very strong |
| 15 | 32,768 | ~800 ms | ~1.25 | ~656 | ⚠️ May impact UX |
> GPU figures assume bcrypt's memory access pattern limits parallelism to ~1 hash per SM; actual throughput varies by driver and implementation.
---
Typical Examples
Example 1 — Startup web app (cost=12)
A Node.js API uses bcrypt.hash(password, 12). On their 2-core VPS (2× AMD EPYC core):
Example 2 — Legacy app rehash migration (cost=8 → cost=12)
An e-commerce platform has 500,000 user records hashed at cost=8. Rehashing all at cost=12:
Example 3 — High-traffic API (cost=14)
A financial services app wants cost=14 (~400 ms). With 8 CPU cores dedicated to auth:
---
Common Mistakes
1. Using cost=10 in 2025 and calling it "secure." Cost=10 was OWASP's recommendation circa 2012. GPU hardware has improved ~10× since then. At cost=10, an RTX 4090 does ~21,000 hashes/s—a 6-char lowercase password is cracked in seconds. Minimum: cost=12.
2. Confusing cost with the number of iterations directly. The cost factor is an exponent: cost=12 means 2¹² = 4,096 rounds, NOT 12 rounds. Developers sometimes increase cost from 12 to 13 thinking it "adds 1 round"—it actually doubles the work.
3. Benchmarking on a dev laptop and deploying to production. A MacBook M3 hashes bcrypt at cost=12 in ~30 ms; a cloud t3.micro (burstable CPU) might take 250–400 ms under load. Always benchmark on production hardware.
4. Ignoring the 72-character password limit. bcrypt silently truncates input at 72 bytes. A user with a 100-character passphrase is effectively hashed at 72 chars. This is a known bcrypt limitation—consider Argon2id if you need full-length support.
5. Not re-evaluating cost annually. OWASP recommends increasing the cost factor as hardware improves. A cost set in 2018 may be inadequate by 2026. Implement a version check in your auth flow to rehash on login when cost is below threshold.
---
Related Calculators
Frequently asked questions
What is the bcrypt cost factor and what values are safe in 2025?
The cost factor (work factor) is a base-2 exponent controlling how many key-expansion rounds bcrypt performs: cost N = 2^N rounds. OWASP's 2025 Password Storage Cheat Sheet recommends a minimum of cost=12 (~100 ms on a modern CPU). Cost=13 or 14 provides stronger protection at the expense of longer login times. Anything below cost=12 is considered insufficient against modern GPU cracking rigs.
How much does increasing the cost by 1 affect hashing time?
Each increment of 1 in the cost factor exactly doubles the hashing time, because the round count is 2^cost. Going from cost=12 (~100 ms) to cost=13 means ~200 ms, and cost=14 means ~400 ms. This doubling applies equally to defenders (login latency) and attackers (cracking speed), so every +1 halves an attacker's throughput.
Why can't GPUs crack bcrypt as fast as they crack MD5?
bcrypt's Blowfish key schedule requires ~4 KB of working memory (the P-array and four 1-KB S-boxes) that must be read/written on every hash. GPU cores have very limited L1 cache per thread, causing massive memory contention when parallelizing bcrypt. An RTX 4090 achieves ~164 billion MD5/s but only ~5,000–21,000 bcrypt/s depending on cost—a slowdown factor of ~10 million. This memory-hardness is by design.
What is the 72-character truncation limit in bcrypt?
The original bcrypt specification (Provos & Mazières, 1999) processes only the first 72 bytes of the password. Characters beyond byte 72 are silently ignored. This means two passwords that share the same first 72 bytes will produce the same hash. For most users (passwords under 30 chars) this is irrelevant, but it matters for passphrases. Argon2id does not have this limitation.
How do I safely migrate a database from cost=10 to cost=12?
The standard approach is opportunistic rehashing: when a user logs in successfully, check whether their stored hash uses a lower cost than your current minimum. If so, rehash their plaintext password (which you have momentarily in memory during authentication) at the new cost and update the database record. No bulk migration needed—the upgrade happens passively as users log in over days or weeks. Users who don't log in remain at the old cost until they do.
Should I use bcrypt, Argon2id, or scrypt in 2025?
OWASP's 2025 recommendation ranks Argon2id as the first choice (winner of the Password Hashing Competition, 2015), followed by scrypt, then bcrypt. Argon2id is memory-hard with tunable memory and time parameters, has no 72-char limit, and is more resistant to GPU/ASIC attacks. However, bcrypt is universally supported across languages and frameworks, making it a solid, pragmatic choice when Argon2id is unavailable. Avoid MD5, SHA-1, SHA-256, and unsalted hashes for passwords entirely.
How does bcrypt prevent rainbow table attacks?
bcrypt incorporates a cryptographic salt—a 128-bit random value generated per password and stored alongside the hash. The salt is incorporated into the Blowfish key schedule, ensuring that even two identical passwords produce completely different hashes. A rainbow table precomputes hash→password mappings, but a unique salt invalidates any precomputed table: an attacker would need a separate table for every possible 128-bit salt, which is computationally infeasible (2^128 entries).
What CPU/server specs should I benchmark bcrypt on before choosing a cost?
Always benchmark on production hardware under expected load, not a dev machine. Key variables: CPU architecture (ARM vs x86), clock speed, available cores dedicated to auth, and whether CPU credits are burstable (e.g., AWS t-series). A useful heuristic: pick the highest cost factor where time per hash stays ≤250 ms on your production server under peak concurrency. For most cloud VMs (2–4 vCPUs), cost=12 hits ~80–150 ms, which is a comfortable operating point.