This trace follows the actual state transitions behind the companion Store Password Verifiers, Not Recoverable Passwords. It describes a common execution path; implementation details can vary, so keep the contract separate from the mechanism.
Step 1: Generate a unique random salt
Password storage should make a stolen database expensive to search. A password hashing function is intentionally slow and memory-intensive compared with a general-purpose hash. Each password needs a unique random salt so equal passwords do not produce equal stored verifiers.
Step 2: Hash with configured parameters
At registration, the service generates a salt and computes a verifier using a password-hashing algorithm with a configured cost. At login, it recomputes the verifier and compares safely. The stored record includes the algorithm parameters so the service can increase cost and rehash after successful authentication.
Step 3: Store verifier metadata
At login, use the stored algorithm parameters and salt to recompute the verifier; compare safely, then rehash successful credentials when policy has strengthened.
At this point, record the state that changed and check the invariant before advancing. If the operation repeats, make clear which values persist and which are recomputed.
Step 4: Recompute during login
Encryption is reversible with a key and is not a substitute for password hashing. A fast hash such as plain SHA-256 permits attackers to test guesses too quickly. No password scheme protects weak user choices completely, so rate limits and multifactor options still matter.
Step 5: Upgrade cost after verification
A database export reveals salts and password verifiers. Explain what salts prevent, what they do not prevent, and why the chosen hash must be expensive to compute.
The trace is complete when the result satisfies the stated contract. Compare this model with the concrete runtime or system you are studying before making a performance claim.