Testing

Chapter 10

Testing, Pitfalls & Hardening Checklist

Auth testing, the broken-auth catalogue, and a deployable checklist

The finale turns the course into practice: how to test an authentication system, the broken-auth patterns to recognize, and a single deployable checklist that pulls all ten chapters — and the whole HTTPS/CSRF/XSS quartet — together.

How to Test Authentication

Auth testing is mostly about probing each part of the lifecycle for the weaknesses each chapter named:

Password storage — confirm hashes are slow + salted (bcrypt/argon2), not MD5/SHA; that you never store or log plaintext.
Login — try brute force / stuffing against rate limits; check for user enumeration via messages and timing; confirm generic errors.
Session — verify the ID is high-entropy & regenerated at login (fixation); check cookie flags; test idle/absolute timeout and that logout truly invalidates server-side.
MFA — confirm it can't be skipped by manipulating the flow; test recovery-code handling; check for MFA-fatigue protections.
Tokens — try alg:none and algorithm swaps; tamper with claims; check token expiry/revocation actually works.
Recovery — test token entropy/expiry/single-use, Host-header poisoning, and that sensitive changes re-authenticate.

Reference the standards — don't test from memory

Two free references make auth testing systematic: the OWASP Authentication Cheat Sheet (and Session Management, Password Storage, Forgot Password cheat sheets) for the "what good looks like," and the OWASP ASVS (Application Security Verification Standard) chapters on authentication and session management for a checklist of verifiable requirements at increasing rigor levels. OWASP ZAP / Burp Suite automate parts (session-token analysis, brute-force, tampering), but the highest-value testing is manually walking each flow against these references. Auth bugs are logic bugs — scanners miss most of them.

The Broken-Auth Catalogue

Broken practice	Why it fails	Chapter
Plaintext / fast-hash / encrypted passwords	breach = mass plaintext recovery	2
No rate limiting / naive lockout	brute force / stuffing; self-DoS	3
User enumeration (message or timing)	lets attackers target real accounts	3
Predictable session IDs	session hijacking by guessing	4
No session regeneration at login	session fixation	5
Missing cookie flags / cookie-only logout	theft, riding, stale sessions	5
SMS-only MFA / weak recovery fallback	SIM-swap; downgrades strong MFA	6
`alg:none` / unverified JWT	forged tokens, identity spoofing	7, 8
OAuth without `state` / loose redirect_uri	callback CSRF, code theft	8
Weak password reset (predictable/eternal/poisonable)	account takeover via recovery	9

The Hardening Checklist

☑

Passwords: slow salted hash (Argon2id / bcrypt≥12); never plaintext/encrypted; upgrade-on-login; breach-check new passwords

☑

Login: rate-limit by IP and account; backoff over hard lockout; generic responses + uniform timing (no enumeration)

☑

MFA: offer TOTP/passkeys; avoid SMS-only; number-matching for push; recovery codes stored hashed

☑

Sessions: high-entropy IDs; regenerate at login; idle + absolute timeout; logout destroys server-side session

☑

Cookies: HttpOnly + Secure + SameSite (+ __Host-) on the session cookie

☑

Tokens: pin the JWT algorithm (no none); short access + revocable/rotating refresh; verify ID-token sig/iss/aud

☑

OAuth/OIDC: auth-code + PKCE; verify state; exact redirect_uri; use OIDC ID token for identity

☑

Recovery: CSPRNG token, hashed, short expiry, single-use; trusted base URL; re-auth + notify on sensitive changes; invalidate sessions on reset

☑

Transport: HTTPS-only + HSTS (login & everything); the credential/session never on plain HTTP

☑

Don't roll your own: use vetted libraries/frameworks/identity providers; configure them strictly

The principle that survives the whole course

If one idea outlasts the details: the entire account-security problem is protecting one secret — the credential, then the session that stands in for it — across its whole life. Store it so a breach can't reverse it (hashing), prove it without resending it (sessions/tokens), keep it confidential in transit (HTTPS) and at rest (HttpOnly/Secure), stop it being guessed (rate limits/MFA), ridden (CSRF/SameSite), stolen (XSS/HttpOnly), or bypassed (recovery hardening). Every chapter is one facet of guarding that secret — and every defence assumes the others hold, which is why account security is only as strong as its weakest link.

How the Course (and Quartet) Fits Together

The arc: establish identity (Ch. 1 foundations, Ch. 2 password storage, Ch. 3 login defences), carry it (Ch. 4 sessions, Ch. 5 session security), strengthen it (Ch. 6 MFA), scale it (Ch. 7 tokens, Ch. 8 OAuth/OIDC), recover it safely (Ch. 9), and verify it all (Ch. 10). And it completes the quartet: HTTPS protects the secret in transit, Authentication establishes and holds it, CSRF stops it being ridden, XSS stops it being stolen. Four courses, one secret, defended end to end.

Hands-On Exercises

Exercise 1

Write an authentication test plan covering password storage, login, session, MFA, tokens, and recovery — naming the specific weakness to probe in each area and how you'd test it (e.g. timing-based enumeration, session-ID regeneration at login, alg:none).

📄 View solution

Exercise 2

Audit this app against the broken-auth catalogue: it stores SHA-256 passwords, has no login rate limit, keeps the same session ID after login, stores JWTs in localStorage, and emails non-expiring reset links built from the Host header. List every flaw, its chapter, and the fix.

📄 View solution

Exercise 3

Produce a prioritized hardening plan for a new web app's auth (cookie sessions, password + optional MFA, email password reset). Order the measures, justify the ordering, and show how the four security courses (HTTPS / Auth / CSRF / XSS) each contribute to protecting the session.

📄 View solution

Chapter 10 Quick Reference

Test each lifecycle stage for its named weakness; auth bugs are logic bugs scanners miss — walk flows manually against OWASP cheat sheets / ASVS
Broken-auth catalogue: weak hashing · no rate limit · enumeration · predictable/un-regenerated session IDs · missing cookie flags · SMS-only MFA · alg:none · OAuth without state · weak reset
Checklist: slow salted hashes · IP+account rate limits · MFA (TOTP/passkeys) · regenerate session at login · HttpOnly/Secure/SameSite · pin JWT alg + verify ID token · auth-code+PKCE · secure reset · HTTPS+HSTS · don't roll your own
The one principle: protect a single secret (credential → session) across its whole life — stored, proven, in transit, guessed, ridden, stolen, recovered
Account security = the weakest link across all of it; each defence assumes the others hold
Completes the quartet: HTTPS (in transit) · Auth (establish/hold) · CSRF (not ridden) · XSS (not stolen)

★ Authentication & Session Security Complete — 10 / 10 chapters

From AuthN-vs-AuthZ foundations through password hashing, login defences, sessions and their security, MFA, tokens and JWTs, OAuth/OIDC, secure recovery, and a deployable hardening checklist. Paired with HTTPS, CSRF, and XSS, you now hold the complete quartet of web account security — four courses defending one secret end to end: stored irreversibly, proven without resending, kept confidential, and never guessed, ridden, stolen, or bypassed.