Quiz Entry - updated: 2026.07.14
In practice, why is salt universally used but pepper more rarely?
Salt is essentially free and self-contained; pepper requires extra deployment plumbing for storage, rotation ("Pepper Rollover"), and disaster recovery.
Why salt is "absolutes Minimum":
- One column in the DB. Generated once, never changes.
- Required by every modern password-hashing function (Argon2 generates it automatically).
- The cost vs benefit is trivially favourable.
Why pepper is harder to deploy:
| Concern | Why it's hard |
|---|---|
| Storage | Must be outside the DB — secrets manager (Vault, AWS Secrets Manager), HSM, or env var |
| Rotation | Changing the pepper invalidates every existing hash → need a "pepper rollover" strategy (e.g. version the pepper, store version with the hash, support both during transition) |
| Disaster recovery | Backup the DB and the pepper, in separate vaults — both are needed to verify passwords |
| Hot deployment | Application server compromise potentially leaks the pepper, putting you back to salt-only protection |
| Multi-region | Every replica needs the pepper synchronised |
Pepper Rollover:
- Generate a new pepper version
pepper_v2. - Hashes computed under
pepper_v1keep working (the version is stored alongside). - On next successful login, re-hash the password with
pepper_v2and update. - After everyone has logged in (or after a deadline), retire
pepper_v1.
Tip: Salt is non-negotiable. Pepper is a defence-in-depth bonus that's worth it for high-value systems (banking, healthcare, password managers). For most apps, "Argon2 + framework's built-in salting" is sufficient.