Authentication

AUTHENTICATION Applied Security · 03 — proving WHO you are: password storage, sessions vs tokens, JWTs, MFA AUTHENTICATION = who are you (prove identity). AUTHORIZATION (l.04) = what may you do. this lesson: store credentials safely, and stay logged in without re-sending the password every request. (shop's real auth path.) 1 · FACTORS & STORING PASSWORDS SAFELY the FACTORS: something you KNOW (password) · you HAVE (phone/key) · you ARE (biometric). MFA = 2+ of these. STORING A PASSWORD — the rules, in order of how people get it wrong: ✗ plaintext (a breach = every password). ✗ ENCRYPTED (reversible → the key leaks too). ✓ HASH it (one-way, l.02). but a bare hash still breaks two ways — and the fixes are the whole point: 'hunter2' password + salt random/user argon2 (SLOW) memory-hard store: hash + salt · SALT (random per user) → makes every hash unique, so precomputed RAINBOW TABLES are useless. · SLOW / memory-hard hash (bcrypt, scrypt, ARGON2) → a GPU can't try billions/sec; tune the work factor UP over time. login: hash the input the SAME way, compare in CONSTANT time (a fast '==' leaks length via timing). extras: a PEPPER (app-wide secret, stored separately) · breach-check (haveibeenpwned) · RATE-LIMIT login attempts (l.rate-limit). the mantra: passwords are HASHED (never encrypted), SALTED (per user), and SLOW (argon2). those three words. 2 · STAYING LOGGED IN: sessions vs tokens after login you must prove identity on EVERY request without the password. two designs: SESSION (stateful): client server store cookie: sid=random server stores the session; client holds a random ID in a cookie; each request the server LOOKS IT UP. easy to REVOKE (delete server-side). – needs server state (shared store / sticky sessions — System Design l.01). TOKEN (stateless — JWT): client verify signature sends signed JWT server issues a SIGNED token; client sends it; server just VERIFIES the signature (l.02) — NO lookup. scales with zero server state. – hard to REVOKE (valid until it expires) → short expiry + a refresh token. rule of thumb: sessions when you need instant revoke / simplicity; tokens when you need scale / cross-service. 3 · THE JWT, DECODED & where to store it a JWT is three base64 parts joined by dots: HEADER . PAYLOAD . SIGNATURE HEADER {alg: HS256} . PAYLOAD (claims) {sub:123, exp:.., role:user} . SIGNATURE HMAC(head.payload, secret) the SIGNATURE (l.02) proves the token wasn't tampered — the server recomputes it to verify. ⚠ the PAYLOAD is only base64, NOT encrypted — anyone can READ it. never put secrets in a JWT. classic JWT pitfalls: the 'alg:none' bypass · a weak/guessable secret · forgetting to check EXP (expiry). WHERE TO STORE the cookie/token — the flags matter: · httpOnly — JavaScript can't read it → survives XSS (l.05). · Secure — HTTPS only. · SameSite — not sent cross-site → blocks CSRF (l.05). ✗ localStorage — readable by any XSS. avoid for tokens. 4 · MFA / TOTP & the whole flow MFA adds a factor beyond the password so a stolen password alone isn't enough: · TOTP (Google Authenticator): a shared secret + the CURRENT TIME → a 6-digit code (it's an HMAC of the timestamp, l.02). both sides compute it independently — nothing sent. · PUSH approval, SMS (weak — SIM-swap), or PHISHING-RESISTANT hardware keys (FIDO2 / WebAuthn / passkeys) — the gold standard, tied to the site's origin. THE AUTH FLOW, ASSEMBLED: register: password + salt -> argon2 -> store hash login: verify hash -> (MFA) -> issue session/JWT request: send cookie/token -> server verifies -> allow logout: delete session / let token expire + rotate authentication answers 'are you who you say?'. get the three password words right (hashed/salted/slow), pick session vs token by your revoke/scale needs, and add MFA. next (l.04): now that we know WHO — what may they DO? JARGON, DECODED authentication (authN) = prove who you are · authorization (authZ, l.04) = what you may do · factors = know/have/are · MFA = 2+ factors · salt = random per-user value defeating rainbow tables rainbow table = precomputed hash→password lookup · bcrypt/scrypt/argon2 = slow, memory-hard password hashes · work factor = tunable slowness · pepper = app-wide secret added before hashing · constant-time compare session = server-side state + a cookie id (revocable) · token/JWT = stateless signed credential (scales, hard to revoke) · JWT = header.payload.signature (payload is readable base64, NOT encrypted) · refresh token = re-issues short-lived access tokens httpOnly / Secure / SameSite = cookie flags (XSS-safe / HTTPS-only / CSRF-blocking) · TOTP = time-based one-time code (HMAC of the clock) · WebAuthn / passkeys = phishing-resistant hardware auth · alg:none = a JWT bypass to know