PBKDF2 Iteration Count from Target Time

Pick a PBKDF2 iteration count that hits a target derivation time given your platform's measured per-iteration cost.

Inputt_iter = t_bench / N_bench , N = round( t_target / t_iter )

Target derivation time (ms)Benchmark iterationsBenchmark measured time (ms)Attacker speedup vs your box — optional

Your recent runs (stored only in your browser)

No calculations yet — results land here so you can compare runs.

The engineering

PBKDF2 stretches a password by running the underlying PRF (HMAC-SHA-256, etc.) a large number of times so each guess costs real work. The right iteration count is not a magic constant — it is whatever number lands your derivation at a tolerable login latency on the hardware you actually ship on. Measure one known count, divide out the per-iteration cost, and scale to your target.

Rule of thumb: keep interactive logins under ~250 ms so users don't notice, then push the count as high as that budget allows. Re-benchmark on your slowest production node, not your dev laptop — a factor-of-ten difference in CPU changes the answer directly. The attacker-rate row reminds you that offline crackers run on GPUs or ASICs many orders of magnitude faster, which is why PBKDF2 is now the floor, not the ceiling — Argon2 or scrypt resist those better.

Where this math comes from

PBKDF2 came out of RSA Laboratories' PKCS #5 work in the late 1990s, written up by Burt Kaliski. The idea was simple and durable: take a password and salt, feed them through a keyed hash thousands of times, and expose the iteration count as a tunable knob so defenders could raise the cost as CPUs got faster. It was standardized as RFC 2898 in 2000.

The scheme was re-issued essentially unchanged as RFC 8018 in 2017, which is telling — the construction aged well even as the recommended iteration counts climbed from a few thousand to hundreds of thousands. Its weakness is that it is cheap to parallelize on GPUs, which is why NIST and OWASP now steer new designs toward memory-hard functions while keeping PBKDF2 as an approved baseline.

2000Burt Kaliski / RSA LabsPublishes PBKDF2 in RFC 2898 (PKCS #5 v2.0) with a tunable iteration count.
2010RSA / NIST SP 800-132PBKDF2 endorsed for password-based key derivation in federal systems.
2015Password Hashing CompetitionArgon2 wins, signaling memory-hard successors to iteration-only stretching.
2017IETF (K. Moriarty et al.)Re-issues the scheme as RFC 8018, the current PKCS #5 reference.

See the full timeline of the math behind every calculator →

Runs entirely in your browser — nothing you enter leaves this page. Your recent runs are stored only on your device.