EXERCISE 1 — Which protection: in transit / at rest / hash?
============================================================

The test:
  - HASH (one-way) -> data you only need to VERIFY, never recover.
  - ENCRYPT AT REST -> stored data you must READ BACK later.
  - ENCRYPT IN TRANSIT (TLS) -> any sensitive data MOVING over a network.
  Many items need MORE THAN ONE.

(a) A user's login password.
    PROTECTION: HASH (slow, salted — Argon2id/bcrypt) AT REST,
                + ENCRYPT IN TRANSIT while it's submitted.
    WHY: you never need the original password back — you verify a login by
    hashing the attempt and comparing. So store a one-way hash, never
    encryption/plaintext. It also travels over the network at login, so the
    submission must be over TLS (HTTPS). (Two protections: hash at rest + TLS
    in transit.)

(b) A credit-card number you must charge monthly.
    PROTECTION: ENCRYPT AT REST (reversible) + ENCRYPT IN TRANSIT.
    WHY: you MUST recover the number to charge it again, so hashing won't work
    — use strong reversible encryption (AES-GCM) with proper key management
    (ideally tokenize / use a PCI-compliant vault so you store as little as
    possible). It's sensitive in transit too -> TLS. (Two protections;
    regulatory: PCI-DSS.)

(c) Data sent from the browser to your API.
    PROTECTION: ENCRYPT IN TRANSIT (TLS / HTTPS) — primarily.
    WHY: the concern is interception/tampering on the wire, so it must travel
    over HTTPS (+ HSTS). Whether it ALSO needs at-rest protection depends on
    what the data IS once stored (if it includes passwords/cards/PII, apply
    (a)/(b)). In transit is the baseline requirement for any sensitive request.

(d) Session tokens stored in the database.
    PROTECTION: HASH AT REST (+ TLS in transit when issued/sent).
    WHY: a session token is a bearer credential (Auth course) — like a
    password, you only need to VERIFY a presented token, not recover it. So
    store a HASH of the token server-side; a DB breach then doesn't hand over
    usable live sessions. The token also travels over the network -> TLS. (Some
    systems store opaque random session IDs and rely on the store's security;
    hashing tokens at rest is the stronger, recommended pattern.)

SUMMARY:
  (a) password .......... hash at rest + TLS in transit
  (b) card number ....... encrypt at rest + TLS in transit (+ tokenize)
  (c) browser->API data . TLS in transit (at-rest depends on contents)
  (d) session tokens .... hash at rest + TLS in transit

KEY IDEA: decide hash-vs-encrypt by "do I ever need the original back?"
(no -> hash; yes -> encrypt), and add TLS for ANYTHING sensitive crossing a
network. Most sensitive data needs both an at-rest AND an in-transit control.