Passwords have perhaps 30 bits of entropy. A fast hash lets an attacker test billions per second against a stolen database. Key derivation functions exist to make each guess expensive, converting the attacker's cheap arithmetic into an expensive one.
Watch the cost
The derivation time readout is the point of this tool. Move the iteration slider and watch it change — that time is what an attacker pays per guess. At 600,000 iterations, a GPU farm that could test ten billion fast hashes per second is reduced by four or five orders of magnitude.
Tune the parameter to your hardware, not to a number from a blog post. Target roughly 250ms on your production hardware for an interactive login, then check the number against current guidance.
Current OWASP guidance
- PBKDF2-HMAC-SHA256 — 600,000 iterations
- PBKDF2-HMAC-SHA512 — 210,000 iterations
SHA-512 needs fewer iterations for equivalent cost because each iteration does more work, and it is somewhat less GPU-friendly. Both are acceptable; SHA-512 is marginally preferable where your platform supports it well.
These numbers rise over time. Store the parameters alongside the hash — which is what the PHC-style record output is for — so you can raise the cost later and re-derive on next login without a migration.
Where PBKDF2 falls short
PBKDF2 is CPU-hard but not memory-hard. It uses almost no memory, so an attacker can run thousands of parallel instances on a GPU or a custom ASIC very cheaply. That is a structural limitation no iteration count fixes.
Argon2id is memory-hard by design: each instance must allocate substantial memory, so parallel attacks become expensive in silicon rather than just in time. It won the Password Hashing Competition and is the current recommendation for new systems.
bcrypt is a reasonable middle ground with a long track record, though it silently truncates inputs past 72 bytes — a real hazard if you pre-hash or accept long passphrases.
Neither is offered here, and the reason is honest: Web Crypto provides neither. Implementing them would mean shipping a large WASM payload for an operation that belongs on your server. This tool implements PBKDF2 natively and tells you plainly where Argon2id is the better choice.
Salt
Sixteen random bytes, unique per password, stored in the clear beside the hash. Its job is to make precomputed rainbow tables useless and to ensure two users with the same password get different hashes. It is not secret, and it does not need to be.
A missing salt means identical passwords produce identical hashes, which tells an attacker which accounts to attack together.
Not for API keys
If the input already has full entropy — a 256-bit random API key — key stretching accomplishes nothing. There is no low-entropy guess space to slow down. Use a single SHA-256 and keep your authentication path fast. The hash calculator is the right tool for that.
Frequently asked questions
How many iterations should I use?
Enough to take about 250ms on your production hardware, and no fewer than the OWASP figure. The meter on this page compares your setting to that guidance.
Should I use Argon2 instead?
For a new system, yes, using a maintained server-side library. For an existing PBKDF2 deployment, raising the iteration count is a smaller change with most of the benefit; migrate opportunistically at next login rather than all at once.
Is it safe to type a real password here?
The derivation runs in your browser and nothing is transmitted. That said, deriving a real production password in a browser tab has no purpose — use this to tune parameters with a test value.
What is the PHC-style record for?
It stores the algorithm, iteration count, salt and hash in one string. That means you can raise the cost later without a migration: read the parameters from the stored record, verify with them, and re-hash at the new cost on successful login.