Storing a verifier rather than recovering the password
A scheme processes the password, salt and cost into a record. Later verification recomputes with the recorded parameters and checks the candidate, without requiring a decryption key recovering every original password.
The record remains sensitive. Possession allows offline candidate tests outside the website’s direct login-rate limit, so avoiding plaintext storage does not make a leaked verifier database harmless.
References: [1]
Intentionally increasing cost per guess
General digests often prioritize speed, whereas a password scheme deliberately sets a cost per candidate. Memory-hard designs such as Argon2 tune memory, passes and parallelism rather than equating security with output length or an arbitrary repetition of a fast hash.
Cost is not unbounded: legitimate latency, concurrency and memory constrain settings. NIST guidance ties practical cost and later adjustment to verifier performance and records algorithm parameters for migration, rather than prescribing one timeless numeric setting.
Salt, password entropy and extra secrets differ
Appropriate salts reduce identical records for equal passwords and reuse of precomputation across accounts. They are normally stored with the result and do not enlarge the password’s original secret space; per-record guessing remains possible.
An independently protected verifier secret can add another layer and differs from public salt. Input normalization, record versions, parameters and online attempt limits still need definition. General derivation such as HKDF does not automatically replace password-specific hardening.