Password Hash Cost Calculator (bcrypt, PBKDF2)

Understanding the password hash cost calculator — concept and principle

Password hashes such as bcrypt and PBKDF2 are deliberately slow, so that an attacker who steals a password database can test only a limited number of guesses per second. This calculator shows how bcrypt's cost factor changes the hashing time on your server, how many internal iterations it represents, and whether a PBKDF2-HMAC-SHA256 iteration count meets the OWASP recommendation of 600,000.

The stacks double at each step; cost 12 is the default example.

How it is calculated

bcrypt time (ms) = measured time at cost 10 × 2^(cost − 10)
bcrypt iterations = 2^cost
PBKDF2 check: "yes" if iterations ≥ 600,000, otherwise "no".

Measure the time at cost 10 on your own hardware first; the calculator then scales it. The cost factor is the exponent stored in the bcrypt hash string, for example $2b$12$….

The principle

bcrypt's expensive key setup repeats the Blowfish key schedule 2^cost times, so each step of +1 doubles the work for you and for every attacker. This exponential knob lets you raise the cost as hardware gets faster without changing the algorithm. PBKDF2 works linearly instead: it applies HMAC repeatedly for the chosen number of iterations, so doubling the iterations doubles the time. Both are CPU-bound; memory-hard functions such as Argon2id also force attackers to spend memory, which makes GPU and ASIC attacks more expensive, and are OWASP's first choice.

Worked example

Inputs: cost 12, 60 ms measured at cost 10, PBKDF2 with 600,000 iterations.
Scale factor: 2^(12 − 10) = 4.
bcrypt time: 60 × 4 = 240 ms per hash.
Iterations: 2^12 = 4,096.
PBKDF2: 600,000 ≥ 600,000, so the check is yes.

Each point is the calculator re-run with only “bcrypt cost factor” changed; the gold point is the default example. Change the inputs above and this chart follows your numbers.

bcrypt cost factor	bcrypt time at this cost (ms)
3	0.46875
6	3.75
9	30
12	240
15	1,920
18	15,360
24	983,040

How to read the result

Pick the highest cost your login servers can afford under peak load. Each login costs one hash, so 240 ms of CPU per attempt limits how many logins a core can serve; many teams target a few hundred milliseconds. For an attacker, the same 240 ms means one core tries only about four guesses per second. OWASP's current guidance is Argon2id first, bcrypt with a work factor of at least 10, or PBKDF2-HMAC-SHA256 with at least 600,000 iterations.

Common mistakes

Copying a cost value without timing it on your own servers.
Forgetting that bcrypt uses only the first 72 bytes of the password.
Treating a fast hash such as plain SHA-256, even salted, as a password hash.
Never raising the cost; re-hash with a higher cost when users log in.

Keep in mind: The time scaling is an estimate; real timings vary with hardware, load and library. Follow the current OWASP Password Storage Cheat Sheet and your organisation's security policy, and have the design reviewed for production systems.

Frequently asked questions

What bcrypt cost should I use?

At least 10 per OWASP; choose the highest value whose measured latency your servers can afford.

Is PBKDF2 still acceptable?

Yes, it is FIPS-compliant and widely supported, but it needs a high iteration count because it is not memory-hard.

Do I need a salt with bcrypt?

bcrypt generates and stores a random 128-bit salt automatically inside the hash string.

Sources: OWASP Password Storage Cheat Sheet · N. Provos and D. Mazières, "A Future-Adaptable Password Scheme", USENIX Annual Technical Conference, 1999 · RFC 8018, PKCS #5: Password-Based Cryptography Specification Version 2.1 (PBKDF2)

Checked 8 Nov 2026. Standard formulas and RFC/IEEE definitions, computed locally in your browser — nothing you type is sent anywhere.

Your numbers