How to use this salt and hash iteration guide
Pick the algorithm you plan to use, enter the PBKDF2 iteration count you measured, the time that run took, and your target time. The page works back to the highest iteration count that still fits the target. Add a salt length and a user count and it also reports how many distinct salts exist and how likely a repeat is. The bcrypt cost value itself is out of scope.
How it is calculated, and the source
PBKDF2 time scales almost linearly with iterations, so the ceiling is measured iterations x (target time / measured time), rounded down. Salt repeats are approximated with the birthday problem over 2^(8 x bytes) values. The per-algorithm positions come from the OWASP Password Storage Cheat Sheet, checked in October 2026.
Limits and cautions
OWASP states plainly that there is no golden rule for the ideal work factor. This page never runs a hash, so a measurement taken on different hardware will skew the result. Pushing the cost too high exhausts CPU first during a login flood, which becomes self-inflicted downtime. No single setting makes a system safe on its own.
Frequently asked questions
A salt is not a secret; it is stored beside the hash. Its job is to stop identical passwords from producing identical hashes, which is what makes precomputed tables work. What it must be is unique and random per user, since a single global salt removes the benefit.
OWASP states there is no golden rule. For PBKDF2 it names 600,000 iterations or more where FIPS-140 is required, and keeping one hash under one second is the general guidance. Measure on the same CPU class you run in production and work back from that.
OWASP puts Argon2id first for new systems, scrypt when Argon2id is unavailable, PBKDF2 where FIPS-140 is required, and bcrypt for legacy use. This page lays those positions side by side; it does not make the choice for you.