Loading Password Hashing Cost Calculator…
PBKDF2-HMAC-SHA256 is timed in this browser, at the iteration count you choose, using the same derivation this site stores its own admin password with. Nothing is sent anywhere and no password is involved — the input is a fixed string, because only the cost is being measured.
At or above the 600,000 iterations OWASP publishes for PBKDF2-HMAC-SHA256.
An assumption you set, not a benchmark. Purpose-built hardware runs PBKDF2 thousands of times faster than a browser, and no single figure for that stays true for long.
Nothing measured yet. The button above runs the derivation three times and keeps the fastest, which is the run least disturbed by whatever else this machine is doing.
From the OWASP Password Storage Cheat Sheet. The stronger hash needs fewer iterations because each one costs more, so all three land at roughly the same wall-clock cost.
PBKDF2 is the weakest of the choices worth making. Its work is arithmetic, which is what a GPU has thousands of cores for, so an attacker’s advantage over your server is enormous and grows every hardware generation. Argon2id and scrypt are also memory-hard: they demand a working set no amount of parallelism makes cheaper, which is why OWASP puts them first. PBKDF2 earns its place where nothing else is available — a browser, an edge runtime, FIPS-constrained code — and this site’s own login is exactly that case.
Iterations are the last line of defence, not the first. A unique salt per password (which this derivation generates) is what stops one rainbow table breaking every account at once, and rate limiting is what stops the online guessing that no work factor slows down. The iteration count only matters once the database is already gone.
PBKDF2 has one dial. Run the underlying HMAC once and a stolen database can be attacked at the speed of a raw hash; run it six hundred thousand times and every guess costs six hundred thousand times as much. The same multiplier applies to your own login, which is the trade the number encodes: an attacker with a copy of the table and a person signing in both pay it, and only one of them is in a hurry.
Because the cost is measured in work rather than seconds, a figure copied from an article written three years ago quietly becomes weaker every year as hardware improves. Measuring is the only way to know where you actually stand, which is what the button on this page does.
The measurement runs a genuine derivation — PBKDF2-HMAC-SHA256, a 16-byte salt, a 256-bit output, the same call this site stores its own admin password with — three times, and keeps the fastest. The fastest run is the honest one: it is the sample least disturbed by whatever else the machine was doing, and an attacker will not be sharing a core with a video call.
From that one figure everything else follows by arithmetic. An iteration count that fits a 250 millisecond login is the measured rate multiplied by a quarter of a second, rounded down to two significant figures because the measurement does not justify more precision. Your production server is not this browser, so treat the result as the shape of the answer and repeat the measurement where the code will run.
Cracking hardware is quoted here as a multiplier you choose, not as a benchmark. Any specific figure for a graphics card is out of date within a year and wrong for whichever card an attacker actually owns, and this project has already deleted calculators that presented invented reference values as facts.
The keyspace times are exact arithmetic over an assumption: half the combinations, at the rate the multiplier implies. Real attacks never look like that. They start with the passwords already leaked from other breaches, then the predictable ones, and most accounts fall long before an exhaustive search would reach them — so read those rows as the ceiling for a password chosen at random, not as a forecast for the passwords you have.
The OWASP Password Storage Cheat Sheet publishes 600,000 iterations for PBKDF2-HMAC-SHA256, 1,300,000 for SHA-1 and 210,000 for SHA-512 — different numbers for roughly the same wall-clock cost, because each pass of a wider hash does more work. Those are the figures this tool compares against, and the site’s own login uses the SHA-256 one.
The same document puts Argon2id and scrypt ahead of PBKDF2, and the reason is memory. PBKDF2 is pure arithmetic, exactly what a graphics card has thousands of cores for, so the attacker’s advantage over your server is enormous. Argon2id also demands a large working set that parallel hardware cannot conjure cheaply. PBKDF2 remains the right answer where nothing else is available — a browser, an edge runtime, a FIPS-constrained stack — and picking a defensible iteration count is how you make the best of that.
Measure on the hardware that will run it, pick the largest count that fits your login budget under realistic load, and never go below the published figure for your hash. Then write down when you chose it, because it needs revisiting.
Different silicon, and different contention. A browser gets a quiet core and a native crypto implementation; a busy server runs many derivations at once, and a container with a fraction of a CPU allocated to it is slower again under load.
Not directly, because the stored value was derived at the old cost and the password itself is gone. Store the count alongside each hash, then re-derive at the new figure the next time that user signs in successfully.
Barely. Online guessing is limited by your rate limiting and lockout policy, which stop thousands of attempts a second regardless of the work factor. Iterations matter after the database has been copied, where no rate limit applies.