Authentication answers "who are you?" Get it wrong and attackers become other users. The category covers everything from accepting weak passwords, to leaking sessions, to broken password-reset flows that any attacker can drive. Most failures aren't dramatic — they're a thousand small defaults that combine into "log in as anyone."
← Back to SecurityUse Argon2id (preferred), bcrypt, or scrypt. Never plain SHA-256 or MD5 — they're designed to be fast, which is exactly the wrong property for a password hash. Modern algorithms are deliberately slow and memory-hard so brute force scales poorly.
Tune work factors so a single hash takes ~250–500ms on your hardware. Rehash on login if a user's stored work factor is below current.
Every password gets its own random salt. bcrypt and Argon2 do this for you and store the salt in the hash itself. Without a salt, two users with the same password get identical hashes — and rainbow tables become useful again.
Modern guidance (NIST SP 800-63B): minimum 8 characters, allow up to 64+, no forced complexity rules, no periodic rotation. Block known-breached passwords using haveibeenpwned's k-anonymity API instead. Long passwords beat clever passwords, and "must contain a symbol" rules push users toward predictable substitutions.
Stolen passwords are everywhere — billions of them, sortable, free. MFA defeats credential-stuffing categorically because the attacker doesn't have the second factor. Microsoft and Google have publicly reported MFA stops >99% of automated account takeovers.
If "I lost my MFA" downgrades you to email-only verification, attackers will go straight there. Recovery codes printed at enrollment and a slow path (hours to days, with notifications) is far safer than a one-click reset.
Spring Session, Express-session with a secure store, ASP.NET cookie auth, Django sessions. Don't roll your own session ID generator — frameworks use cryptographic randomness, store securely server-side, and rotate IDs on privilege change.
HttpOnly (no JS access — limits XSS damage), Secure (TLS only), SameSite=Lax or Strict (CSRF defense), __Host- prefix for production. Set them on every session cookie.
Issue a new session ID after authentication and after role escalation. Otherwise, "session fixation" attacks work — the attacker sets a cookie before login and inherits the authenticated session afterward.
Tokens that live forever are forever-lost when leaked. Use short access tokens (minutes) and longer refresh tokens (days/weeks) that can be revoked server-side. Rotate refresh tokens on use; detect reuse as an attack signal.
alg: none. Pin the expected algorithm — don't trust the header.iss, aud, exp, nbf, signature.exp; keep tokens short and use refresh-token rotation.Limit login attempts per IP, per username, per device fingerprint. Use exponential backoff and CAPTCHAs after failures. Block credential-stuffing patterns (high attempts across many usernames from one source). Don't lock out users permanently — that's a denial-of-service the attacker can drive.
Login from a new country, a new device, a new ASN. Step up to MFA, send a notification, or quarantine the session. Most takeovers are visible in the access pattern; you have to be looking.
For most apps, the right answer is don't write the auth system yourself. Auth0, Okta, Cognito, Clerk, Firebase Auth, WorkOS, Stytch, Supabase Auth — they handle MFA, social login, password breach checks, account recovery, and audit. They're cheaper and safer than rolling your own.