SaaS password storage: Argon2id hashing and migration guide
Store customer passwords with an adaptive password-hashing function such as Argon2id, unique salts, tuned work factors and safe rehashing; never store plaintext or use a fast general-purpose hash.
In this guide
How should a SaaS app store user passwords?
Do not store passwords in plaintext or reversible encryption. Store a password verifier made with a dedicated, adaptive password-hashing function such as Argon2id, using a unique salt and cost settings tested on your production hardware. Use the framework’s supported password-hashing API so algorithm parameters and migration behavior are handled consistently. Password hashing reduces the harm of a database leak; it does not protect a live account from phishing or credential reuse.
Prefer a dedicated adaptive password-hashing function
Use Argon2id when it is supported by your runtime and deployment. OWASP lists baseline Argon2id configurations, including 19 MiB of memory with two iterations and parallelism one, and a higher-memory equivalent; measure the current guidance and tune for your system. If policy requires a validated cryptographic module, select a compliant option such as the documented PBKDF2 profile rather than assuming every library meets that requirement.
Use a unique salt and keep the encoded verifier intact
A trusted password-hashing library should generate a fresh salt for each password and store algorithm and cost metadata with the encoded verifier. Do not invent a salt format, reuse one global salt or strip parameters from the stored result. Compare candidate passwords with the library’s verification function using constant-time behavior supplied by the framework.
Keep fast hashes and reversible storage out of password verification
General-purpose hashes such as SHA-256 are designed to be fast and make large-scale guessing cheaper when stolen. Encryption is reversible and usually the wrong storage model for a password that only needs verification. Do not create home-grown constructions such as an undocumented sequence of hashes; use a supported password hasher and a clear upgrade path.
| Runtime / framework | Algorithm and current parameters | Login latency and capacity test | Legacy hash migration rule | Owner and review date |
|---|---|---|---|---|
| Production web app | ||||
| Background authentication service | ||||
| Legacy imported accounts |
How should teams tune and maintain password hashes?
Benchmark cost against both user experience and abuse load
A stronger hash costs more work for every login and password change. Benchmark on production-like instances, set a reasonable latency target and load-test peak concurrent sign-ins. Rate-limit abusive attempts and capacity-plan accordingly; an expensive setting without admission controls can itself make authentication unavailable.
Rehash successful logins when the stored settings are outdated
When a person enters the correct password, check whether the stored verifier uses an obsolete algorithm or lower work factor. If the framework supports it, compute a new verifier and update it safely after successful verification. Keep a recovery plan for dormant accounts and weak legacy formats rather than attempting to reverse a one-way hash.
Treat an optional pepper as a separately managed secret
A pepper can add defense in depth when stored outside the password database, for example in an approved secret manager or key service. It adds operational complexity and recovery needs, and it does not replace a unique salt or a strong adaptive hash. Document rotation and incident handling before adopting one.
How can an engineering team verify password storage?
Inspect stored account records without exposing live passwords
In a controlled test database, confirm each account has an encoded verifier with a unique salt and expected algorithm metadata. Check that logs, analytics, support tools, exports and backups do not contain plaintext passwords or reset tokens. Do not ask staff to retrieve a user’s original password; the system should be unable to do so.
Test verification, upgrade and failure behavior
Test valid and invalid passwords, account creation, password changes and the legacy rehash path. Confirm malformed or unknown hash formats fail safely and do not bypass the ordinary authentication policy. Exercise peak login load after changing cost parameters, and monitor latency and error rates before broad rollout.
Plan a safe path away from legacy credentials
Inventory hash algorithms and versions without copying credential material into reports. Prefer rehash-on-success when compatible; for formats that cannot be safely verified or are known compromised, assess a reset or staged migration with security and customer-support owners. Protect the process from account enumeration and preserve MFA and session policies.
SaaS password-storage questions
Can a SaaS company decrypt a properly stored password hash?
A password hash is designed for verification, not recovery. The system should verify a candidate password without being able to retrieve the original password.
Is SHA-256 a good password-hashing algorithm?
No, not by itself. It is fast, which helps an attacker test guesses quickly after a database theft. Use a dedicated adaptive password hasher and tune its work factor.
Does bcrypt work for every possible password length?
Bcrypt has a 72-byte input limit in common implementations. Review the exact library behavior and avoid silent truncation; choose a modern hasher and consistent input rules where possible.
Do we need to reset every password when increasing hash cost?
Often a successful login can be rehashed with the current parameters. A reset may be needed for certain unsafe or unverifiable legacy formats, but decide from the stored format and risk rather than applying a blanket reset automatically.
Related practical guides
Related issue guides
Sources and publication record
Draft prepared 27 September 2026; engineering, security and editorial review pending · Sources checked .
- OWASP Password Storage Cheat SheetOWASP Foundation
- OWASP Forgot Password Cheat SheetOWASP Foundation