Storing passwords, and why you should not store them

Password hashing is one of the few areas of application security with a settled answer. No architectural trade-off, no dependence on context: there are three correct choices and everything else is wrong.

What makes people choose wrongly is that the word "hash" carries two entirely different meanings:

SHA-256 is not "weak" — it is an excellent hash for what it was designed for. The problem is that it is fast, and fast is the worst possible property for a password: a modern GPU tries billions of SHA-256 per second, so an 8-character password hashed with SHA-256 falls in hours, salt or no salt.

Salt solves a different problem and is routinely thought to solve this one. Salt defeats rainbow tables and stops two users with the same password sharing a hash — it does not make cracking one specific password slower. That is the work factor's job.

The parameters to use, per the OWASP Password Storage Cheat Sheet:

The bcrypt trap is worth knowing: it silently discards every byte past the 72nd. With a long passphrase, or a Vietnamese password with diacritics (2–3 UTF-8 bytes per character), the tail is dropped with no warning.

But the better question than all three rows above is: do you need passwords? Store no password and there is nothing to leak, nothing to hash wrongly, and nobody reusing their password from a site that was already breached. Passkeys (WebAuthn) and OIDC with a provider both remove this problem rather than solving it.