EXERCISE 1 — Which lifecycle stage each A07 failure breaks
==========================================================

The credential/session lifecycle: STORE the credential (hashing) -> PROVE
identity at LOGIN -> carry it as a SESSION -> RECOVER it safely. Each A07
failure breaks one stage.

(a) Plaintext passwords.
    STAGE: STORE (how the credential is kept at rest).
    DEFENCE: store a slow, SALTED, one-way HASH (Argon2id / bcrypt) — never
    plaintext or fast hashes or "encryption." A DB breach then doesn't hand over
    usable passwords. (Auth Ch. 2; also A02.)

(b) No login rate limit.
    STAGE: LOGIN / PROVE (defending the act of authenticating).
    DEFENCE: rate-limit by IP AND account, with backoff/temporary locks; add
    breach-password checks, generic responses + uniform timing (no enumeration);
    push MFA. Stops brute force, credential stuffing, and spraying. (Auth Ch. 3.)

(c) The same session ID after login.
    STAGE: SESSION (managing the credential's stand-in).
    DEFENCE: REGENERATE the session ID on login (anti-fixation); use high-
    entropy IDs, idle+absolute timeouts, server-side logout, HttpOnly/Secure/
    SameSite cookies. Otherwise an attacker who planted a known pre-login ID
    owns the authenticated session. (Auth Ch. 4-5.)

(d) Password reset via security questions.
    STAGE: RECOVERY (the alternate path to access).
    DEFENCE: use single-use, expiring, hashed reset TOKENS emailed out-of-band;
    re-authenticate sensitive changes; DON'T use security questions (answers are
    public/guessable). Recovery is the #1 takeover vector. (Auth Ch. 9.)

SUMMARY:
  (a) STORE     -> hash (slow, salted)
  (b) LOGIN     -> rate limit + no enumeration + MFA
  (c) SESSION   -> regenerate at login + cookie flags + timeouts
  (d) RECOVERY  -> secure token, no security questions, re-auth

THE ONE UNIFYING IDEA:
  Authentication is about PROTECTING ONE SECRET — the credential, then the
  SESSION that stands in for it — ACROSS ITS WHOLE LIFE. Every A07 failure is a
  gap at one stage of that life: stored unsafely (a), guessed at login (b),
  hijacked/fixated as a session (c), or bypassed via recovery (d). Get all
  stages right, because account security is set by the WEAKEST link among them.