bcrypt Cost Factor: Time per Hash & Cracking Resistance
Calculate bcrypt time per hash by cost factor (work factor / rounds). See ms per hash, hashes/sec and the OWASP-recommended cost for 2026, with a full reference table.
See step-by-step calculation
The cost factor is an exponent of base 2: cost=N means bcrypt performs 2^N internal key-expansion rounds. So cost=10 runs 1,024 rounds, cost=12 runs 4,096 rounds, cost=14 runs 16,384 rounds, and so on. Each +1 in cost exactly doubles the hashing time — both for legitimate logins on your server and for an attacker cracking the hash offline. The bcrypt specification allows costs from 4 to 31, but practical values for password hashing in 2026 are between 10 and 14.
On a modern single CPU core (AMD EPYC / Intel Xeon / consumer x86, 2024-2026 generation), a useful reference point is ~65 ms per hash at cost=10. From there it doubles cleanly: cost=12 ≈ 260 ms, cost=14 ≈ 1,040 ms (≈1 second). OWASP's 2025-2026 Password Storage Cheat Sheet sets the recommended bcrypt floor at cost=10, with cost=12 widely used as the modern default because it lands in the ~250 ms range — fast enough for user logins, slow enough to make offline brute-force economically prohibitive on commodity GPU hardware.
bcrypt has three important properties beyond raw slowness: (1) a built-in 128-bit random salt per password, generated automatically and stored alongside the hash, which makes rainbow-table attacks infeasible; (2) modest memory hardness — bcrypt's Blowfish key schedule needs ~4 KB of working state (the P-array and four 1-KB S-boxes), which severely limits GPU and ASIC parallelism compared to MD5; (3) a 72-byte truncation limit on the input password, a quirk of the original spec you must work around for very long passphrases.
This calculator estimates the wall-clock time per hash at any cost factor on a reference modern CPU core, plus approximate throughput in hashes per second and a security recommendation tuned to 2026 hardware. Always benchmark on your production hardware before committing a cost factor to production: a MacBook Pro dev machine can be 3-5× faster than a burstable cloud VM under sustained load, and ARM (Graviton, Ampere) is typically 2-3× slower than x86 at the same cost.
When to use this calculator
- Backend engineer setting a secure bcrypt cost factor for a new SaaS authentication system, targeting ~200-300 ms per login on the production cloud VM without degrading UX. The calc shows cost=12 ≈ 260 ms (the common default) and cost=11 ≈ 130 ms.
- Security team auditing a legacy PHP app using cost=8 (~16 ms, considered insecure) and quantifying the migration cost: rehashing 2 million stored hashes at cost=12 (260 ms each) requires ~520,000 CPU-seconds — about 6 days on a single core, or ~18 hours parallelized across 8 cores.
- Capacity planner for a high-traffic banking login endpoint estimating concurrent bcrypt verifications per server: at cost=12 (260 ms/hash) and 8 cores dedicated to auth, the theoretical ceiling is ~31 logins/second; peak traffic of 20 logins/sec leaves comfortable headroom.
- Pentester estimating attacker cracking speed on a 4× NVIDIA RTX 4090 rig (each card does a few thousand bcrypt/s at cost=12) against a stolen hash table; for an 8-char random alphanumeric password (62^8 combinations) the average case runs into decades, illustrating why bcrypt slowness matters.
- DevOps engineer setting an opportunistic rehash policy: on successful login, if the stored hash uses a cost below your minimum, transparently rehash the plaintext at the new cost and update the DB. The calc helps justify the chosen minimum given current hardware.
- Compliance auditor checking PCI-DSS requirement 8.3.2 (render passwords unreadable using strong cryptography) for a payment processor: bcrypt cost=12 comfortably satisfies the rule for 2025-2026; cost=8 raises an audit finding.
- CTO evaluating Argon2id vs bcrypt for a new mobile-backend API: bcrypt is universally supported in Node.js, Python, Go, Ruby, Rust and PHP, has 25+ years of cryptanalysis with no practical breaks, and the calc shows cost=12 ≈ 260 ms at acceptable cost — a pragmatic choice when Argon2id libraries are unavailable.
- Embedded systems developer prototyping authentication for an ARM Cortex-A53 IoT device: the same cost=12 that runs in ~260 ms on x86 takes 600-900 ms on the ARM SBC. The calc helps choose cost=10 or 11 as a compromise between security and UX on lower-power hardware.
bcrypt Cost Factor: Rounds, Time & Security Rating (2026 Reference)
| Cost | Rounds (2^cost) | Time/hash (1 CPU core) | CPU hashes/s | GPU hashes/s (RTX 4090, approx) | Security rating (2026) |
|---|---|---|---|---|---|
| 8 | 256 | ~16 ms | ~62 | ~350,000 | ❌ Insecure |
| 10 | 1,024 | ~65 ms | ~15 | ~21,000 | ✅ OWASP minimum |
| 11 | 2,048 | ~130 ms | ~7.7 | ~10,500 | ✅ Good |
| 12 | 4,096 | ~260 ms | ~3.8 | ~5,250 | ✅ Recommended default |
| 13 | 8,192 | ~520 ms | ~1.9 | ~2,625 | ✅ Strong |
| 14 | 16,384 | ~1,040 ms (~1 s) | ~1.0 | ~1,312 | ✅ Very strong |
| 15 | 32,768 | ~2,080 ms (~2 s) | ~0.5 | ~656 | ⚠️ May impact UX |
Fuente: OWASP Password Storage Cheat Sheet (2025-2026). Referencia base: 65 ms/hash a cost=10 en un core x86 moderno (AMD EPYC / Intel Xeon, 2024-2026); cada +1 en cost duplica el tiempo. GPU limitada por el patrón de acceso a memoria de bcrypt (~4 KB por hash). Siempre realizar benchmark en hardware de producción.
How it works
How 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 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
Reference used by this calculator (modern single CPU core):
T_ref = 65 ms at cost_ref = 10
Time(12) = 65 × 2^(12−10) = 65 × 4 = 260 ms
Time(14) = 65 × 2^(14−10) = 65 × 16 = 1,040 ms ≈ 1 s
Hashes per second (single core):
hashes_per_sec = 1,000 ms / Time(cost in ms)> Note: bcrypt is memory-hard in the sense that it needs ~4 KB of RAM per hash (the Blowfish P-array + four S-boxes), which severely limits GPU parallelism compared to pure compute-bound hashes like MD5. The 65 ms reference is a typical modern x86 core; your hardware will differ — always benchmark in production.
---
bcrypt Cost vs Time Reference Table
Values use the calculator's reference of 65 ms per hash at cost=10 on one modern CPU core, doubling for every +1. Real benchmarks (hashcat, john-the-ripper, bcrypt.js) land in this range on 2024-2026 hardware; GPU figures (NVIDIA RTX 4090) are approximate and limited by bcrypt's memory access pattern.
| Cost | Rounds (2^cost) | Time/hash (1 CPU core) | CPU hashes/s | GPU hashes/s (RTX 4090, approx) | Security rating (2026) |
|---|---|---|---|---|---|
| 8 | 256 | ~16 ms | ~62 | ~350,000 | ❌ Insecure |
| 10 | 1,024 | ~65 ms | ~15 | ~21,000 | ✅ OWASP minimum |
| 11 | 2,048 | ~130 ms | ~7.7 | ~10,500 | ✅ Good |
| 12 | 4,096 | ~260 ms | ~3.8 | ~5,250 | ✅ Recommended default |
| 13 | 8,192 | ~520 ms | ~1.9 | ~2,625 | ✅ Strong |
| 14 | 16,384 | ~1,040 ms (~1 s) | ~1.0 | ~1,312 | ✅ Very strong |
| 15 | 32,768 | ~2,080 ms (~2 s) | ~0.5 | ~656 | ⚠️ May impact UX |
> Each row is exactly double the row above. GPU figures assume bcrypt's memory access pattern limits parallelism; 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 a 2-core VPS:
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 vs 13)
A financial services app wants cost=14 (~1,040 ms). With 8 CPU cores dedicated to auth:
---
Common Mistakes
1. Confusing cost with the number of rounds directly. The cost factor is an exponent: cost=12 means 2¹² = 4,096 rounds, NOT 12 rounds. Bumping cost from 12 to 13 doesn't add one round — it doubles the total work.
2. Treating a fixed ms number as universal. bcrypt timing depends entirely on hardware. ~65 ms at cost=10 is a reasonable modern reference, but a fast desktop CPU might do half that and a burstable cloud VM 3-4× more. Always benchmark in production.
3. Benchmarking on a dev laptop and deploying to production. A MacBook M3 may hash cost=12 in ~80 ms; a cloud t3.micro (burstable CPU) might take 600-900 ms under sustained load when CPU credits exhaust.
4. Ignoring the 72-byte password limit. bcrypt silently truncates input at 72 bytes. A 100-character passphrase is effectively hashed at 72 bytes. Pre-hash with SHA-512 (carefully) or switch to Argon2id if you need full-length support.
5. Never re-evaluating the cost factor. OWASP recommends raising cost as hardware improves. A cost set in 2016 may be inadequate today. Implement a version check in your auth flow to rehash on login when the stored cost is below your current minimum.
---
Related Calculators
Worked example — cost = 12
Frequently asked questions
What bcrypt cost factor should I use in 2026?
How much does increasing the bcrypt cost by 1 change the hashing time?
How long does bcrypt take per hash at cost=12?
Why can't GPUs crack bcrypt as fast as they crack MD5 or SHA-256?
What is the 72-byte truncation limit in bcrypt and how does it affect security?
How do I migrate a database from cost=10 to cost=12 without disrupting users?
$2b$10$... prefix means cost=10); (3) if it's below your current minimum, rehash the plaintext (which you hold momentarily during auth) at the new cost and update the DB record atomically. No bulk migration or downtime is needed — the upgrade happens passively as users log in over days or weeks. Inactive accounts stay at the old cost until their next login, which is acceptable since they face lower attack pressure.Should I use bcrypt, Argon2id, or scrypt in 2026?
How does bcrypt prevent rainbow-table attacks?
$2b$cost$22-char-salt$31-char-hash). The salt feeds into the Blowfish key schedule, so two identical passwords produce completely different hashes. A rainbow table precomputes hash→password mappings for a fixed function, but a unique 128-bit salt invalidates any precomputed table — an attacker would need a separate table for every possible salt (2^128 ≈ 3.4 × 10^38), which is infeasible by many orders of magnitude. Salts force attackers into per-account brute-force, which is exactly where bcrypt's slowness does its job.What CPU/server specs should I benchmark bcrypt on before choosing a production cost?
What does a bcrypt hash look like and how do I read the cost from it?
$2b$12$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy. Decoded: $2b$ (also $2a$, $2y$) is the version identifier (2b is the current canonical variant since 2014); 12$ is the cost factor (here cost=12, a two-digit decimal); the next 22 characters are the base64-encoded 128-bit salt; the final 31 characters are the base64-encoded hash output. To read the cost in code, parse the two digits before the second $. Library helpers — bcrypt.getRounds() in Node.js, passlib.identify()/bcrypt__ident in Python, password_get_info() in PHP — do this for you.Is bcrypt vulnerable to timing attacks?
crypto.timingSafeEqual() in Node.js, secrets.compare_digest() in Python, hash_equals() in PHP), never a plain == or strcmp that short-circuits on the first differing byte. Most maintained bcrypt libraries compare in constant time internally, but custom verification logic is a common pitfall. Also avoid leaking bcrypt latency on unauthenticated endpoints — return consistent response times.Can I use bcrypt for API keys or session tokens instead of passwords?
Sources & references
Methodology & trust
Calculadora de tecnología revisada por el equipo editorial de Hacé Cuentas, contrastada con OWASP Password Storage Cheat Sheet – bcrypt recommendations, según nuestra política editorial y metodología.
Última revisión: June 20, 2026. Los parámetros se verifican periódicamente con las fuentes citadas.
Calculations run 100% in your browser. We do not store or transmit your data.
Indicative results. For critical decisions, consult a professional.
Rodríguez, M. (2026). bcrypt Cost Factor: Time per Hash & Cracking Resistance. Hacé Cuentas. https://hacecuentas.com/hashes-bcrypt-costo-tiempo-cracking
Contenido bajo licencia CC-BY 4.0 — reutilizable citando la fuente con enlace a Hacé Cuentas.