Day 44 · Locks, badges and guest lists

Security, AuthN & AuthZ

You will be able to

Distinguish hashing from encryption and explain why passwords are hashed, never encrypted
Explain salted password hashing and why bcrypt/argon2 beat SHA-256 for passwords
Compare sessions and JWTs, including the JWT revocation pitfall
Walk through an OAuth2/OIDC authorization-code flow and name each actor
Apply least privilege and RBAC to an API design

Today's ~125 minutes

Spaced-rep warm-up: due flashcards (incl. Day 43 TLS)	10 min
ELI5 + tech read: locks vs badges vs guest lists	20 min
Guided: salted hashing + JWT by hand	40 min
Practice: the auth design review	20 min
Project: auth memo + password module	25 min
Quiz + flashcards	10 min

Builds on: Day 43 — Networking & TLS · Day 41 — HTTP & your first API · Day 38 — Database internals — where credentials live

The analogy

🧸 ELI5⚙ Tech

An office building runs three separate security systems, and mixing them up is how break-ins happen. The lock on the front door is encryption: anyone with the key can lock and unlock — it is reversible by design. The visitor logbook is hashing: the guard writes a smudge-proof fingerprint of your ID into the book; nobody can reconstruct your ID from the fingerprint, but tomorrow they can check "same person?" by fingerprinting you again. The badge on your lanyard is authentication — it proves who you are. The guest list on each meeting-room door is authorization — being in the building (authenticated) does not mean every door opens for you.

Web security is these systems composed: TLS locks the trucks between buildings (Day 43), password hashes are the fingerprint logbook, sessions and JWTs are the badge, and role checks are the per-door guest list. Most real breaches are not lock-picking — they are a badge that never expires, a guest list nobody prunes, or a logbook that stored the actual IDs instead of fingerprints.

Why this matters on the job

AI applications concentrate risk: they hold API keys worth real money per token, they proxy user data into third-party models, and agents can act with the permissions you give them. "Least privilege" stops being a slogan the day your demo agent has a database tool and a customer asks what stops it from reading other tenants' rows. Every enterprise deal you touch as an FDE begins with a security questionnaire — SSO (OAuth2/OIDC), secrets handling, RBAC — and engineers who can answer precisely close deals faster. On Day 132 prompt injection joins this threat model; today's foundations are what injection attacks try to bypass.

Watch it happen

Badges, not master keys — the OAuth2 authorization-code flow

step 1 / 6

Youbrowser→Appwants access→Auth serverlogin + consent→Token swapback channel→APIyour data

✉ click: "Sign in with Google"

The problem: an app wants to read your calendar, but giving it your password would give it EVERYTHING, forever. OAuth2 issues a scoped, expiring badge instead. It starts with a click.

🎯 Predict modespeed1×

Guided practice

guided 1

Salted, slow password hashing — and why fast is fatal

20 min

Run part 1 of the starter: hash the same password twice with SHA-256. Identical outputs — why is that a problem for a leaked database? (Same password → same hash → crack once, unlock everyone.)
Part 2 salts each hash with random bytes. Confirm the same password now produces different digests, and that verification still works because the salt is stored alongside.
Part 3 uses pbkdf2 with 600k iterations. Time one verification. Multiply: at this cost per guess, how long do 1 billion guesses take on this machine vs plain SHA-256?
Write the two-line summary in your notes: salt defeats precomputation; work factor defeats brute force.

🐍 python — editable, runs in your browser

import hashlib, os, time

pw = b"correct horse battery staple"

# --- 1. naive fast hash: deterministic = crackable in bulk
print(hashlib.sha256(pw).hexdigest()[:32])
print(hashlib.sha256(pw).hexdigest()[:32], "<- identical: bad")

# --- 2. add a per-user salt
def hash_pw(password: bytes, salt: bytes) -> str:
    return hashlib.sha256(salt + password).hexdigest()

s1, s2 = os.urandom(16), os.urandom(16)
print(hash_pw(pw, s1)[:32])
print(hash_pw(pw, s2)[:32], "<- same password, different digests")

# --- 3. add a work factor: pbkdf2 (stdlib stand-in for bcrypt/argon2)
def slow_hash(password: bytes, salt: bytes, iters: int = 600_000) -> bytes:
    return hashlib.pbkdf2_hmac("sha256", password, salt, iters)

salt = os.urandom(16)
t0 = time.perf_counter()
digest = slow_hash(pw, salt)
per_guess = time.perf_counter() - t0
print(f"one verification: {per_guess*1000:.0f} ms")
print(f"1e9 guesses would take ~{per_guess * 1e9 / 86400 / 365:.1f} YEARS here")

# verify flow: recompute with the STORED salt, compare digests
assert slow_hash(pw, salt) == digest
assert slow_hash(b"wrong password", salt) != digest
print("verify OK")

Ctrl/⌘+Enter runs · Tab indents · numpy/pandas/sklearn auto-load on import (torch and network calls need a local run)

guided 2

Build and break a JWT by hand

20 min

JWTs are just base64url + a signature. Building one demystifies every pitfall.

Run the starter: it mints a token with an HMAC-SHA256 signature, then verifies it.
Decode the payload WITHOUT the key (part 2). Lesson one: anyone can read claims — encoded is not encrypted.
Tamper with the payload (change role to admin) and re-verify. The signature check fails — that is the entire security model.
Re-sign the tampered payload WITH the key and watch it verify. Lesson two: whoever holds the signing key mints identity; key management IS auth security.
Check the exp claim logic: set exp in the past and confirm your verify function rejects it. Lesson three: expiry is the only built-in revocation.

🐍 python — editable, runs in your browser

import base64, hashlib, hmac, json, time

SECRET = b"server-side-signing-key"   # in prod: from a secret manager

def b64url(data: bytes) -> str:
    return base64.urlsafe_b64encode(data).rstrip(b"=").decode()

def sign(header: dict, payload: dict, key: bytes) -> str:
    h = b64url(json.dumps(header).encode())
    p = b64url(json.dumps(payload).encode())
    sig = hmac.new(key, f"{h}.{p}".encode(), hashlib.sha256).digest()
    return f"{h}.{p}.{b64url(sig)}"

def verify(token: str, key: bytes) -> dict | None:
    h, p, s = token.split(".")
    expected = hmac.new(key, f"{h}.{p}".encode(), hashlib.sha256).digest()
    if not hmac.compare_digest(b64url(expected), s):
        return None                          # signature mismatch
    pad = "=" * (-len(p) % 4)
    payload = json.loads(base64.urlsafe_b64decode(p + pad))
    if payload.get("exp", 0) < time.time():
        return None                          # expired
    return payload

token = sign({"alg": "HS256", "typ": "JWT"},
             {"sub": "user42", "role": "viewer", "exp": time.time() + 900},
             SECRET)
print(token[:60], "...")
print("verified:", verify(token, SECRET))

# 2. read the payload with NO key — claims are public!
h, p, s = token.split(".")
print("readable:", base64.urlsafe_b64decode(p + "=" * (-len(p) % 4)))

# 3. tamper: forge role=admin, keep old signature -> must fail
forged_p = b64url(json.dumps({"sub": "user42", "role": "admin",
                              "exp": time.time() + 900}).encode())
print("tampered verifies?", verify(f"{h}.{forged_p}.{s}", SECRET))  # None

Ctrl/⌘+Enter runs · Tab indents · numpy/pandas/sklearn auto-load on import (torch and network calls need a local run)

On your own

The auth design review

20 min

A junior teammate proposes this for your Day 42 notes service: passwords stored as SHA-256 (no salt), a JWT with a 30-day expiry containing the user's email and plaintext API quota, admin checks done in the frontend ("we hide the delete button"), and the signing key committed in config.py "so tests pass."

Your goal: write a review with (1) every flaw found (there are at least five), (2) the concrete fix for each, (3) the one-line principle behind each fix (salting, short expiry, server-side authZ, secrets management, least privilege).

Hints: what happens on database leak? On stolen token? On a curl request that skips the frontend? On a public repo?

Ship before you stop

Auth decision memo + password module

Two deliverables in your practice repo. (1) auth_memo.md: for the notes service you will harden tomorrow, decide sessions vs JWT vs API keys for its two clients (a web UI and a CLI script), justify in a paragraph each, and draw the OAuth2 authorization-code flow as a numbered ASCII sequence with all four actors. (2) auth_lib.py + tests: hash_password, verify_password (salted pbkdf2, constant-time compare), and new_api_key (returns the key once, stores only its hash). Tomorrow (Day 45) this module gets wired into the real service — write it like production code.

Rubric — check what you completed (0/6)

Memo chooses an auth mechanism per client with a stated threat it defends againstOAuth2 flow diagram names client, resource owner, authorization server, resource server in the right orderhash_password embeds a random salt; verify_password uses hmac.compare_digestAPI keys are stored hashed; the plaintext is only ever returned at creationpytest suite covers wrong password, tampered hash, and duplicate-password-different-hashCommitted with a descriptive message

Common mistakes & misconceptions

Encrypting passwords instead of hashing them. Encryption is reversible — a stolen key un-scrambles every password. Hashing has no way back; leaks expose fingerprints, not credentials.
Using fast hashes (SHA-256/MD5) for passwords. They are built for speed; attackers get billions of guesses per second. Use bcrypt/argon2/pbkdf2 with a real work factor.
Treating a JWT as encrypted. The payload is base64url — anyone can read it. The signature prevents tampering, not reading. Never put secrets in claims.
Long-lived JWTs "for convenience." A stolen 30-day token is a 30-day breach with no revocation. Short access tokens + refresh tokens is the standard shape.
Enforcing authorization in the client. Hiding the admin button stops nobody with curl. Every permission check must happen server-side, on every request.
Committing secrets to git "temporarily." Git history is forever; scanners find keys in minutes. Env vars or a secret manager from day one (Day 16 already gave you the config pattern).

Knowledge check

Q1. Why must password hashes be salted?

Q2. Your service must invalidate a specific user's access RIGHT NOW. Which design makes this trivially easy?

Q3. In the OAuth2 authorization-code flow, why does the app exchange the code for a token on its BACKEND rather than in the browser?

Go deeper — curated resources

docsOWASP Top Ten — web application risks ↗25 min docsOWASP Cheat Sheet Series — Password Storage & Session Management ↗20 min docsFastAPI Security tutorial — OAuth2 with JWT ↗30 min docsMDN: HTTP authentication ↗15 min

If you have a third hour

The alg:none and key-confusion JWT attacks — Historic libraries trusted the token's own alg header — attackers set "none" or swapped RS256/HS256 to forge tokens. Rule: the server pins the algorithm, never the token.

Done means

Both guided labs run; tamper test demonstrably fails verification
Design review finds ≥ 5 flaws with fixes and principles
auth_lib.py committed with passing tests
OAuth2 flow drawn from memory with all four actors
Quiz ≥ 2/3

How this connects

← Back: TLS from Day 43 secures the wire; today secures identity and permission on top of it. The env-var config discipline from Day 16 is exactly where signing keys and secrets belong, and Day 38 told you where credential tables live.

Forward →: Tomorrow (Day 45) you wire auth_lib into the real service. On Day 132 prompt injection attacks the NEW identity problem — an LLM that can be talked into misusing its permissions — and the least-privilege habit you built today is the main defense. Day 159 extends this into production compliance, and Day 169 covers enterprise SSO in the field.

Unlocks: D45 Web Service Architecture · D125 Agent Reliability · D159 Production Security & Compliance Basics · D169 Enterprise Integration