Security and Privacy

📘 Learn Security and Privacy from zero

Security is keeping the wrong people out of your system and your data. Privacy is making sure even the right people (including you, the operator) only see data they genuinely need. They overlap but are not the same: a system can be secure (no breaches) yet privacy-violating (it logs everyone's location forever).

Analogy: a hotel. The front desk checking your ID is authentication — proving who you are. Your room key opening only your room is authorization — what you're allowed to access. The sealed envelope you mail from the lobby, which staff can route but not read, is end-to-end encryption. Housekeeping not writing down what's in your suitcase is privacy — minimizing what's collected and retained.

Worked example: a login flow. (1) User submits email + password over TLS so no one on the network can sniff it. (2) Server compares the password against a stored bcrypt hash (with a per-user salt) — it never stores the raw password, so a database leak doesn't expose passwords. (3) On success, the server issues a signed token (JWT) the client sends on later requests, so it doesn't re-check the password every time. (4) Each request is then checked for authorization: is this user allowed to call this endpoint, on this resource? (5) For privacy, the system collects only the email it needs, encrypts stored data at rest, and grants each service only the access it requires — the principle of least privilege.

This maps to the classic CIA triad: Confidentiality (encryption, access control), Integrity (signatures and hashes prove data wasn't tampered with), and Availability (rate limiting, DDoS protection keep the service up). Two more design principles ride alongside it: defense in depth (layered controls, no single point of failure) and least privilege (every actor gets the minimum access it needs).

Key insight: security is layered defense — authentication, authorization, encryption, and data minimization are distinct controls, and a strong design names the specific one that matches each specific threat, rather than waving at "we'll make it secure."

✨ Added by the guide to build intuition — not from the source course.

🎯 Guided practice

1. Easy — "Design how passwords are stored for a web app."

   Step 1: Identify the threat — the database could be stolen, so plaintext or reversible encryption is unacceptable.

   Step 2: Choose a one-way slow hash: Argon2 (or bcrypt/scrypt). Reject fast hashes (MD5, raw SHA-256) — attackers brute-force billions/sec on a GPU.

   Step 3: Add a unique salt per user so two users with the same password get different hashes, defeating precomputed rainbow tables. (The salt is stored alongside the hash; it's not secret — its job is uniqueness, not concealment.)

   Step 4: At login, hash the submitted password with the stored salt and compare. Never decrypt — there is nothing to decrypt.

   Pattern learned: for secrets you only ever need to verify, not recover, use a salted slow hash, not encryption.

2. Medium — "Design private 1:1 messaging where even the company can't read messages."

   Step 1: Restate the requirement — "company can't read" means plaintext must never exist on the server. That rules out server-side encryption-at-rest alone (the server holds the key there).

   Step 2: Reach for end-to-end encryption (E2EE). Each user has a key pair; in practice this is hybrid — the asymmetric keys establish a shared symmetric session key, and that key encrypts the actual messages (fast and what real systems do). The recipient's private key never leaves their device.

   Step 3: Handle key distribution — the server runs a key directory that stores and serves public keys, but never private keys. Mention forward secrecy (e.g. the Signal protocol's Double Ratchet) if pushed: keys rotate per message, so past messages stay safe even if one key later leaks.

   Step 4: State the tradeoffs explicitly — the FAANG signal. E2EE means the server cannot do server-side search, content moderation, or message dedup, and account recovery is hard (lose the device, lose the keys). It also doesn't hide metadata (who talked to whom, when) unless you design for that separately. You're trading functionality for confidentiality.

   Pattern learned: when the trust boundary excludes the server itself, push encryption to the client endpoints and keep only public key material server-side.

✨ Added by the guide — work these before the full problem set.