Key Takeaways: Authentication

A one-page reference. Reread before an exam or before moving on. Dense by design.

The three authentication factors (memorize cold)

MFA = factors from different categories. A password + a security question is one factor twice (both knowledge) — not MFA. Security comes from the independence of the categories.

NIST 800-63 authenticator assurance levels (AAL)

Rule: match the AAL to the value/risk of what is protected. Money movement + admin → AAL3.

Password storage (never store the password)

• Salt defeats precomputation (rainbow tables); slow/memory-hard hash defeats brute-force speed. You need both — they counter different attacks.
• Salt is not secret; its job is uniqueness. Generate per user; store with the hash.

Password policy — modern NIST (unlearn the old rules)

Entropy: $H = L \times \log_2 N$ bits — only for random choices. Human-chosen passwords have far less effective entropy than the formula says → breach-screening beats composition rules.

MFA strength ladder (weakest → strongest)

Why FIDO2 is phishing-resistant (the two reasons)

1. No relayable secret — the user produces a signature, not a code; a fake page captures nothing reusable.
2. Origin binding — the browser binds the signature to the site's real origin; a signature for the phishing domain is rejected by the real site (and the authenticator holds no key for the look-alike domain).

Private key never leaves the authenticator; the relying party stores only the public key (breaching it exposes nothing). Passwordless ≠ phishing-resistant (a magic link is passwordless but phishable).

Biometrics

• Irrevocable (can't reissue a fingerprint) · probabilistic (FAR/FRR/CER) · only as trustworthy as the measuring device.
• FAR (false accept) ↔ FRR (false reject) trade off with the threshold; CER (where FAR = FRR) compares systems (lower is better).
• Correct use: a local gesture to unlock an on-device key — never a network secret or a central raw-image database.

Credential attacks — by shape and defense

ATO detections: impossible travel; MFA-prompt bursts; new-device/new-location authenticator enrollment; password reset → immediate MFA change; session-token reuse from a new IP.

The unphishable-login paradox

When the login becomes phishing-resistant, attackers attack the account-recovery / help-desk path instead. Secure re-authentication, not just authentication: strong recovery verification, second-person approval for high tiers, cool-downs, backup keys as the primary recovery path, and an alert on every high-tier authenticator change.

Certification crosswalk

Project additions this chapter

• Meridian program: the authentication standard — AAL-by-asset-tier (Tier 3 = phishing-resistant FIDO2 for money movement + admin, no exceptions); Argon2id storage; modern password policy; hardened account recovery.
• bluekit toolkit: authn.py — password_strength(pw) (length + variety + common-password screen) and breached_prefix(sha1_prefix) (HIBP-style k-anonymity: send only the first 5 hex chars).

Common pitfalls

• Calling a second knowledge factor "two-factor" (it isn't — same category twice).
• Hashing passwords with a fast/unsalted algorithm, or storing them reversibly.
• Trusting composition rules and 90-day rotation (NIST now discourages both); skipping breach-screening.
• Deploying hardware keys but leaving a phishable fallback factor also accepted for the same tier.
• Confusing passwordless with phishing-resistant.
• Using a biometric as a network secret or storing raw biometric images centrally.
• Relying on per-account lockout against spraying (it slips under), or as your only guessing defense (DoS risk).
• Hardening the login but leaving account recovery / the help desk as a chatty open back door.