Authentication and Session Flaws
Even with the right password hashing (Chapter 2) and MFA (Chapter 3), the login and session machinery has its own failure modes — credential stuffing against reused passwords, session fixation, tokens that do not rotate or expire, and account-recovery flows weaker than the login they protect. These let an attacker become a user without ever "cracking" anything.
This topic covers the web-layer authentication flaws and the defenses that close them on Meridian, the machinery around the credentials rather than the credentials themselves.
Credential Stuffing and Brute Force
Attackers replay username and password pairs from other breaches at scale, because users reuse passwords — so the credentials are already valid and no cracking is needed. Rate limiting, MFA, breached-password checks, and bot detection are the counters. Note that these defenses target the replay, not the password strength, since the passwords in a stuffing attack are by definition correct somewhere.
Session Lifecycle Flaws
A session ID that is not regenerated at login lets an attacker fixate a known session on the victim; one that never expires or is not invalidated at logout lets a stolen session ride indefinitely. Sessions must be regenerated on login and privilege change, and killed on logout and timeout — the lifecycle is as much a security control as the login itself.
Weak Account Recovery
"Forgot password" and email or phone recovery are often the weakest link: predictable reset tokens, no rate limiting, or recovery that skips MFA turn the recovery flow into the front door. This is the same point as Chapter 3's MFA-bypass warning, from the web-flaw side — the strongest login is undone by a recovery path anyone can walk.
Enumeration and Timing Leaks
Login and recovery responses that reveal whether an account exists — a different message or a different response time for a known versus unknown user — help attackers build target lists. Uniform responses and constant-time checks close the leak, so probing the login tells the attacker nothing about who has an account.
- No rate limiting or lockout, letting credential-stuffing and brute-force run unchecked against valid, reused passwords.
- Not regenerating the session ID on login, enabling session fixation, and not expiring or invalidating sessions on logout or timeout.
- Account recovery weaker than login — predictable tokens, no MFA, no rate limit — so attackers bypass strong auth via "forgot password."
- Username enumeration through distinct error messages or response timing, feeding targeted attacks.
- Accepting passwords already known to be in breach corpora.
- Rate-limit and monitor authentication, reject known-breached passwords, and require MFA so stuffing valid credentials still fails.
- Regenerate session identifiers on login and privilege change, set idle and absolute timeouts, and invalidate on logout.
- Hold account recovery to the same strength as login — MFA, rate limits, unpredictable single-use tokens.
- Return uniform responses and constant-time behavior to prevent account enumeration.
- Detect and alert on credential-stuffing patterns — many accounts, one source, high failure rate.
Knowledge Check
Why does MFA defend against credential stuffing when a strong password policy does not?
- The passwords are valid, so a second factor stops it
- Stuffing only works against short, low-entropy passwords
- A strong password policy blocks all replay attacks
- MFA makes the password hash uncrackable
What is session fixation, and how is it prevented?
- Attacker pre-sets the session ID; regenerating it at login stops it
- The session never expires; longer timeouts fix it
- The password is reused across sites; breached-password checks fix it
- Cookies are unencrypted; TLS fixes it
Why is a weak "forgot password" flow so dangerous even when login is well-protected?
- Reset via the weaker recovery path
- Recovery flows are slower and frustrate users
- A weak recovery flow disables the login page
- It only matters if the site lacks HTTPS
You got correct