Bcrypt Cost Calculator

Frequently Asked Questions

How does the bcrypt cost factor affect work?

The cost (work factor) sets the number of key-expansion rounds to 2^cost. Going from cost 10 to 12 quadruples the work, since 2¹² ÷ 2¹⁰ = 4.

How long does one hash take at a given cost?

Time per hash ≈ 2^cost ÷ (hashes per second your hardware achieves at cost 0-equivalent), but in practice you benchmark it: a typical server lands near 100 ms per hash around cost 12.

What cost factor should I use?

Pick the highest cost that keeps a single hash near 100–250 ms on your production hardware, commonly cost 10–13 in 2026. Re-benchmark periodically because faster CPUs let attackers and you both go higher.

How many hashes can an attacker try?

Attacker throughput = their hardware hashes/sec ÷ 2^cost relative to your baseline. Each +1 to cost halves their guessing rate, which is why raising the cost directly slows brute-force attacks.

Provided by AllCalculators.io
Free online calculators for everyday. No registration required.

Estimates for informational purposes only.

Important Disclaimer: Estimates for informational purposes only.

This calculator provides estimates for informational purposes only. Results are based on assumptions and may not reflect actual outcomes. Consult qualified professionals in relevant fields before making important decisions based on these results.

JavaScript is required to use the interactive calculator above. The questions and answers below remain readable without JavaScript.

How This Calculator Works

Bcrypt is a deliberately slow password-hashing function. Its "cost factor" (also called work factor or rounds) is a small integer, typically 10–14, and it controls how much work each hash takes: the internal key-setup loop runs 2^cost iterations. Raising the cost by one doubles the time, which is the whole point - it keeps password hashing painfully slow for an attacker doing billions of guesses while staying tolerable for your login endpoint doing one hash per sign-in. This calculator turns a cost factor into the iteration count, estimates how long a single hash takes from a hashes-per-second benchmark on your hardware, projects how many guesses an attacker with that speed could try, and recommends the cost factor that lands closest to a sensible per-hash target (commonly around 250 ms). Use it to pick a cost that is secure today and to re-tune it as hardware gets faster.

Formula / Method

Iterations per hash = 2^cost. If your benchmark says the machine computes H hashes per second at this cost, then the time for one hash is 1 ÷ H seconds. Because each increment of the cost doubles the work, the time at a different cost c is (1 ÷ H) × 2^{(c − cost)}. To recommend a cost for a target time T (seconds), we solve 2^{(c − cost)} = T × H, giving c = cost + log₂(T × H), rounded to the nearest integer and clamped to bcrypt's legal 4–31 range. The attacker-throughput figure is simply H × 3600 guesses per hour at this cost - a reminder that lowering the cost to speed up logins also speeds up offline cracking by the same factor.

Worked Example

Suppose at cost 12 your server measures 50 hashes per second. One hash takes 1 ÷ 50 = 0.02 s = 20 ms. The iteration count is 2¹² = 4,096. An attacker with the same hardware could try 50 × 3,600 = 180,000 guesses per hour against one hash - slow, which is what you want. If you target 250 ms per hash, solve c = 12 + log₂(0.25 × 50) = 12 + log₂(12.5) = 12 + 3.64 ≈ 15.64, rounding to a recommended cost of 16, which would take roughly 0.02 × 2⁴ = 0.32 s per hash. In practice you would pick cost 15 (≈ 160 ms) or 16 (≈ 320 ms) depending on how much login latency you can absorb.

Common Mistakes

Benchmarking on a fast laptop and shipping that cost to a slower server - tune on production-equivalent hardware.

Treating cost as linear - going from 10 to 13 is not 30% more work, it is 8× (2³) more.

Setting the cost so high that logins take seconds - that invites a denial-of-service vector via the login endpoint.

Never revisiting the cost - hardware doubles in speed every few years, so a cost chosen long ago is now too cheap.

Ignoring bcrypt's 72-byte password truncation - very long passwords are silently cut, which matters for security design.

Tips & FAQ

What cost should I use? Pick the highest cost whose per-hash time your login budget tolerates - around 100–300 ms is a common sweet spot, which is usually cost 12–14 today. Is higher always better? Up to a point - too high and legitimate logins lag and the endpoint becomes a DoS target. How do I upgrade existing hashes? Re-hash on next successful login with the new cost; you cannot upgrade a stored hash without the plaintext. Should I use bcrypt at all? Argon2id and scrypt are memory-hard and resist GPU/ASIC attacks better; bcrypt remains acceptable but Argon2id is the modern first choice. Why does bcrypt resist GPUs? Its Blowfish key schedule needs frequent small-memory accesses that map poorly to massively parallel GPU cores. Does the salt affect timing? No - bcrypt always uses a per-hash salt and the cost alone sets the speed. These figures are planning estimates; always benchmark your real stack and re-tune the cost periodically as hardware improves.

Frequently Asked Questions

Related Developer Tools Calculators