Authentication and Session Security

• A login bypass or session leak is the crown-jewel incident: one account, one cookie, whole kingdom.
• The OWASP lists identity/session flaws near the top every year because they are the easiest to exploit and the hardest to undo.
• MFA and session hygiene are the difference between 'credential leaked' and 'breach' in modern forensics.

The key is fine until it stops expiring, stops being unique, or outlives the stay.

• Passwords are stored as salted hashes (bcrypt/argon2) never plaintext; login compares against the computed hash.
• A session is a server-side token (or signed cookie) given at login; the cookie flags (HttpOnly, Secure, SameSite) decide how transportable it is.
• JWT is a stateless alternative: signed claims with expiry, refreshed at an appropriate interval.
• Recovery flows (reset link, security questions, recovery codes) are convenient → high-value targets; they must be equally hardened.

• An org stores only bcrypt hashes and rotated the pepper; a DB leak of the hash table brings attackers brute-force pain.
• A SaaS enforces MFA via TOTP, rotates sessions on password change, and revokes a session the instant a logout request lands.
• A bank's password-reset requires the email link AND a one-time code, closing the 'researcher links' attack the standard reset had.

• Store passwords as bcrypt/argon2 with per-user salt; never MD5/SHA-1/plaintext.
• Set HttpOnly; Secure; SameSite=Lax on session cookies; keep sensitive routes behind proper auth.
• Expire sessions on idle timeout and on password change; honor logout server-side.
• Protect recovery: rate-limit reset, bind links to time + user, and expire them fast.

• Using JWT as a 'session' without revocation — logout does nothing because the token still validates.
• Only clearing the client cookie on logout, leaving a live server session.
• No MFA on admin accounts, then a stolen password equals system admin.
• Rate-limiting login but not the reset endpoint where the attacker actually sits.

• Inspect the Set-Cookie header for the flags; missing HttpOnly is the first thing to fix.
• Reproduce logout bugs by replaying the old cookie after logout — a 200 means the server never ended it.
• Examine reset flows twice: once as the email owner, once replaying the old link.

• Session logs must exclude raw credentials; only hash-based verification records are stored.
• Design recovery flows so a flighted support agent cannot reset passwords without a second factor.
• All session tests happen on your own accounts; don't prod real user sessions, even 'just to test'.