The safest password database is the one you don’t run. Before we get to how to hash, it’s worth asking whether you need passwords at all.
The case for not having passwords
Passwords bring a stack of liabilities: hash storage, reset flows, password manager UX, rotation policies, breach notification requirements. Every one of those is a compliance surface and a potential incident. Look at your use case honestly:
- B2C consumer app → consider passwordless (magic links, passkeys, OAuth)
- B2B SaaS with any enterprise ambition → you’re going to ship SSO anyway; passwords become the minority path
- Internal tools → SSO via Google Workspace or similar is table stakes
If you can credibly offer “sign in with magic link” or “sign in with Google/Microsoft” as the default, you may not need passwords at all. Your support burden drops, your compliance story simplifies, and your users stop getting locked out by Chrome’s password manager.
If you do need passwords
Then the rules are:
Hash with Argon2id. Memory-hard, timing-attack resistant, the current standard recommendation from OWASP and most crypto bodies. Start at memory=64MB, iterations=3, parallelism=4 — tune based on how much login latency your users tolerate. bcrypt is still acceptable if you have legacy constraints, but Argon2id is strictly better for new systems.
Per-user salts, built into the hash. Every modern library does this automatically; don’t roll your own.
Skip pepper. It adds key management overhead for marginal benefit. Focus that effort on database encryption and access controls instead.
Rotate cost parameters over time. Set a target hash time (say, 500ms on your production hardware). When hardware gets faster, increase the cost. Rehash on next login using the new parameters.
Password requirements (get these right)
- Minimum length 8, encourage 12+. Don’t cap max length below 64.
- Check against known-compromised password databases (Have I Been Pwned has a free API).
- No composition rules (“must contain a special character”). They push users toward predictable patterns.
- No rotation policies unless compliance requires them. Forced rotation produces weaker passwords, not stronger.
NIST SP 800-63B codifies all this. If an auditor pushes back on your “no periodic rotation” stance, point them there.