This trace follows the actual state transitions behind the companion Store Password Verifiers, Not Recoverable Passwords. Each step below names its concrete inputs; values illustrate the mechanism and vary across implementations.
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.
Checkpoint: At login, use the stored algorithm parameters and salt to recompute the verifier; compare safely, then rehash successful credentials when policy has strengthened. Confirm this state before advancing to Recompute during login.
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 done when this check holds: A database export reveals salts and password verifiers. Compare the outcome against the companion article before making a performance claim.
Hardware, runtime, and observability notes
When tracing Trace: Store Password Verifiers, Not Recoverable Passwords in a live production environment (subsystem: execution, primary layer: crypto), keep the following step-level cost model and diagnostic checklist in mind:
- Step 1 (crypto): Generate a unique random salt — verifies state invariants before advancing the execution pointer.
- Step 2 (crypto): Hash with configured parameters — verifies state invariants before advancing the execution pointer.
- Step 3 (crypto): Store verifier metadata — verifies state invariants before advancing the execution pointer.
- Step 4 (crypto): Recompute during login — verifies state invariants before advancing the execution pointer.
- Step 5 (crypto): Upgrade cost after verification — verifies state invariants before advancing the execution pointer.
Every transition across the crypto boundary carries both a direct CPU/memory cost (cache-line fills, descriptor lookups, lock acquisitions, or context switches) and a tail-latency queueing risk under contention. To verify this trace on your own service, capture latency histograms and hardware/kernel counters across each step boundary, compare cold-cache versus warm-cache execution paths, and confirm that error or timeout branches release all acquired descriptors, locks, and buffers cleanly.