Password Storage and Account Security Done Properly

Password handling is a solved problem that continues to be implemented badly, usually because the rules people remember are the ones that were current fifteen years ago.

Storage

• Use a deliberately slow, memory-hard hashing algorithm designed for passwords, with a unique salt per user generated by the library.
• Never use a fast general-purpose hash — they're built for speed, which is exactly what an attacker wants.
• Never encrypt passwords. Encryption is reversible; that's the whole problem.
• Tune the work factor to your hardware, and revisit it periodically as hardware improves.
• Never log a password, never email one, and never let support see one. If you can tell a user their password, your design is wrong.

Rules that help and rules that harm

• Require length — a reasonable minimum, and allow long passphrases up to a generous limit.
• Check new passwords against a list of known breached and common passwords. This blocks the passwords actually used in attacks.
• Drop composition requirements. Forcing a symbol and a digit produces predictable substitutions and drives people to reuse.
• Drop scheduled expiry unless a specific compliance regime demands it; it reliably produces weaker, incremented passwords.
• Allow paste, and don't block password managers. Blocking them makes passwords weaker, not stronger.

Protect the login itself

• Rate limit by account and by address, with progressive delays rather than instant permanent lockout, which is itself a denial-of-service route.
• Respond identically whether the username exists or not — on login, on reset, and on registration — to avoid confirming which accounts exist.
• Notify users of new sign-ins from unfamiliar devices, and of password and email changes, to the previous address as well.
• Offer a second factor, and require it for administrative accounts.

Sessions and reset

• Regenerate the session identifier on login to prevent fixation, and invalidate all sessions on password change.
• Reset tokens: single-use, short-lived, random, and invalidated after use or after a new one is requested.
• Store session cookies with the secure, httpOnly, and sameSite attributes set.
• Give users a visible list of active sessions with the ability to revoke them.