CS 161, Lesson 32, in 54 slides. It covers the five password risk vectors in section 14.1, eavesdropping and SSL/TLS in section 14.2, client-side malware and two-factor authentication in section 14.3, and the statistics of online guessing in section 14.4. It then covers the mitigations - rate limiting, CAPTCHAs, and password requirements - in section 14.5, and server compromise and why you must never store cleartext, in section 14.6. It is anchored to textbook sections 14.1 to 14.6.
Subject: Computer Security · 82 slides · applied lesson
Open the interactive version of this deck · Homework for this lesson
Title
CS 161 · Lesson 32 of 45
the five risk vectors · eavesdropping & TLS · malware & 2FA · the statistics of online guessing · rate-limits, CAPTCHAs · and why you must never store cleartext
Objectives
Warm-up
Discussion prompt
Before we open L32 · Password Risks & Mitigations: without looking back, what was the main idea of L31 · Certificates, PKI, Chains, Revocation & Web of Trust, and what could you do by the end of it that you could not do before?
Hint: One sentence for the idea, one for the skill. If the second one is blank, that is the part to revisit.
Answer:
CS 161, Lesson 31, in 53 slides. It covers the public-key authenticity problem and the trusted directory, in sections 13.1 and 13.2, then self-validating digital certificates in section 13.3, and PKI and certificate authorities with the HTTPS trust model in section 13.4. It goes on to certificate chains and hierarchical PKI in section 13.5, revocation through validity periods and CRLs in section 13.6, and the web of trust together with leap-of-faith, or TOFU, in sections 13.7 and 13.8. It is anchored to textbook sections 13.1 to 13.8.
Concept
Passwords are the most-deployed authentication method on earth — and the most attacked. They have a usability problem at their core: a strong password is hard to remember, so users pick weak ones and reuse them across sites.
Matching
Match the pairs
From Three questions this lesson answers — match each one to what it actually does. The descriptions have been shuffled.
Why: What can go wrong?, How do we defend?, What about the server? are easy to tell apart while they are sitting next to their descriptions and much harder afterwards, which is what this checks.
Section
Part 1 · §14.1 where the attacker sits
Concept
Passwords trade security against memorability. A password strong enough to resist guessing is hard to remember; an easy one is easy to guess. Users resolve the tension the lazy way: weak passwords, written down, and reused across many sites.
That reuse is the hinge of this whole lesson: when ONE site is breached, the attacker can try the same password on the user's other accounts. Hold onto that — it returns in §14.6.
Concept
There isn't one 'password attack' — there are five, each defined by where the attacker is relative to the login. Defending one does nothing for the others.
| Risk vector | Where the attacker sits | Defense preview |
|---|---|---|
| Online guessing | At the login form, trying passwords | Rate-limit, CAPTCHA (§14.5) |
| Social engineering / phishing | Talking to the user | User training, 2FA, origin-binding |
| Eavesdropping | On the network path | SSL/TLS (§14.2) |
| Client-side malware | On the user's machine | Two-factor auth (§14.3) |
| Server compromise | Inside the server's DB | Don't store cleartext; hash (§14.6, L33) |
Comparison
Comparison matrix
From §14.1 Five places an attacker can sit: refill the Where the attacker sits column from what you know. The rest of the table is as it appeared.
| Risk vector | Where the attacker sits | Defense preview |
|---|---|---|
| Online guessing | At the login form, trying passwords | Rate-limit, CAPTCHA (§14.5) |
| Social engineering / phishing | Talking to the user | User training, 2FA, origin-binding |
| Eavesdropping | On the network path | SSL/TLS (§14.2) |
| Client-side malware | On the user's machine | Two-factor auth (§14.3) |
| Server compromise | Inside the server's DB | Don't store cleartext; hash (§14.6, L33) |
Concept
One vector doesn't attack the system at all — it attacks the user. In phishing, the attacker tricks the user into typing their password into a fake page that looks like the real login.
Notice it's password-strength-proof: the user voluntarily hands over the secret, however strong. The defense isn't a better password — it's user awareness plus origin-bound credentials and 2FA (⊕ FIDO2/WebAuthn, Synthesis).
Counterexample
Discussion prompt
One vector doesn't attack the system at all — it attacks the user. In phishing, the attacker tricks the user into typing their password into a fake page that looks like the real login.
That is stated as though it always holds. Do one of two things: produce a case where it fails, or say precisely what rules such a case out. "It just does" is not on the menu.
Hint: Hunt at the extremes first — zero, one, negative, empty, equal. If every extreme survives, the reason they survive is the proof.
Intuition
Each vector is a different attacker position, and a position determines what the attacker can see and do. Someone on the network sees bytes in flight; someone on your laptop sees your keystrokes; someone in the database sees stored secrets.
So no single fix covers all five. TLS encrypts the network but does nothing about a keylogger on your machine. A strong password resists guessing but is irrelevant to malware that reads it as you type.
Ask yourself: if you make your password longer and more random, which of the five vectors does that actually help? (Mainly online guessing — and not much else.)
Analogy
Discussion prompt
Explain §14.1 Why 'where the attacker sits' is the right frame by analogy to something with no Computer Security in it at all — a queue, a recipe, a map, a bank balance, whatever fits. Then say where your analogy breaks.
Hint: An analogy that never breaks is not an analogy, it is the same idea wearing a hat. Find the seam — that is the part that is actually new.
Answer:
Ask yourself: if you make your password longer and more random, which of the five vectors does that actually help? (Mainly online guessing — and not much else.)
Pattern
Predict first
The table runs: Online guessing | Only the login API's accept/reject | Limit/slow guesses · Phishing | Whatever the user types into a fake page | Train users; phishing-resistant 2FA · Eavesdropping | Network bytes | Encrypt the channel (TLS) · Malware | Every keystroke / screen | Second factor not on that device
In §14.1 Map each vector to its defense, given the rows so far: what is the next one — the row where Vector is Server compromise?
Correct: Server compromise | The stored password store | Store only one-way hashes
| Vector | Attacker sees | Right defense |
|---|---|---|
| Online guessing | Only the login API's accept/reject | Limit/slow guesses |
| Phishing | Whatever the user types into a fake page | Train users; phishing-resistant 2FA |
| Eavesdropping | Network bytes | Encrypt the channel (TLS) |
| Malware | Every keystroke / screen | Second factor not on that device |
| Server compromise | The stored password store | Store only one-way hashes |
Why: The relationship between the columns, not the individual numbers, is what generates the next row. The defense is determined by the attacker's position, so locating the attacker first prevents mismatched fixes (e.g.
Worked example
Place the attacker for each vector before naming a defense
Why: The defense is determined by the attacker's position, so locating the attacker first prevents mismatched fixes (e.g. 'use TLS' against a keylogger).
| Vector | Attacker sees | Right defense |
|---|---|---|
| Online guessing | Only the login API's accept/reject | Limit/slow guesses |
| Phishing | Whatever the user types into a fake page | Train users; phishing-resistant 2FA |
| Eavesdropping | Network bytes | Encrypt the channel (TLS) |
| Malware | Every keystroke / screen | Second factor not on that device |
| Server compromise | The stored password store | Store only one-way hashes |
Verify: a 'stronger password' only moves the online-guessing row
Why: §14.1: password strength raises the guessing cost but leaves phishing, eavesdropping, malware, and a cleartext-storing breached server untouched. Different positions need different defenses.
Trade off
Comparison matrix
From §14.1 Map each vector to its defense: every row here is a choice with a cost. Fill the Attacker sees column, then say which row you would actually pick and what you give up for it.
| Vector | Attacker sees | Right defense |
|---|---|---|
| Online guessing | Only the login API's accept/reject | Limit/slow guesses |
| Phishing | Whatever the user types into a fake page | Train users; phishing-resistant 2FA |
| Eavesdropping | Network bytes | Encrypt the channel (TLS) |
| Malware | Every keystroke / screen | Second factor not on that device |
| Server compromise | The stored password store | Store only one-way hashes |
Anomaly
Predict first
A student writes this, and it looks reasonable:
A student: 'If I pick a 20-character random password, I'm safe from every password attack.'
It is wrong. Say what breaks — and say it before you turn the page.
Correct: A keylogger reads your strong password as you type it; a cleartext-storing server hands it to the breach attacker verbatim; a phishing page collects it directly.
A student: which vectors does password strength actually help?
Why: A keylogger reads your strong password as you type it; a cleartext-storing server hands it to the breach attacker verbatim; a phishing page collects it directly. Strength only helps against GUESSING.
Trap
A student: 'If I pick a 20-character random password, I'm safe from every password attack.'
Assume password strength covers all five vectors
Why: Wrong. A keylogger reads your strong password as you type it; a cleartext-storing server hands it to the breach attacker verbatim; a phishing page collects it directly. Strength only helps against GUESSING.
A student: which vectors does password strength actually help?
Recognize strength only raises the online-guessing cost
Why: §14.1: malware, eavesdropping, phishing, and server breach defeat any password no matter how strong. You need TLS, 2FA, rate-limits, and hashing — a different defense per position.
Section
Part 2 · §14.2 encrypt the channel
Concept
If a login sends the password as cleartext over the network, anyone on the path — famously, someone on the same open WiFi — can read it straight off the wire. No cracking required; the password is just sitting in the packet.
This is the eavesdropping vector: the attacker sits on the network path between the browser and the server.
Concept
Send the password over an encrypted channel — HTTPS, i.e. SSL/TLS. The eavesdropper now sees only ciphertext, so the cleartext password never appears on the wire.
SSL/TLS (HTTPS) — The standard protocol for an encrypted, authenticated channel between browser and server. It is the canonical defense against password eavesdropping: the login still sends the password, but inside an encrypted tunnel.
Explain it
Discussion prompt
Explain §14.2 The standard defense: SSL/TLS to a student a year behind you. No notation, no jargon they have not met — and it still has to be true.
Hint: If your explanation needs a symbol they have never seen, you are describing the notation rather than the idea.
Answer:
Send the password over an encrypted channel — HTTPS, i.e. SSL/TLS. The eavesdropper now sees only ciphertext, so the cleartext password never appears on the wire.
Concept
There's a clever alternative so the password never leaves the browser: the server sends a random challenge r, and the browser replies with a hash that mixes the password and r.
\[ \text{server} \to \text{browser}: r \quad;\quad \text{browser} \to \text{server}: H(w, r) \]
This is implementable in JavaScript, but in practice it offers little advantage over SSL — and has shortcomings of its own. TLS is the standard answer.
Intuition
At a glance, 'the password never leaves the browser' sounds strictly better. But the JavaScript that does the hashing was delivered by the server over the same network — so an active attacker who can tamper with the page can just swap in code that leaks the password anyway.
TLS already protects the channel that delivers that JavaScript AND everything else on the page. The challenge-response trick protects one field while leaving the rest exposed. That's why it 'offers little advantage over SSL.'
Ask yourself: if you don't trust the network, can you trust JavaScript the network just handed you? (No — which is exactly why you want TLS underneath.)
Anomaly
Predict first
A student writes this, and it looks reasonable:
A student: 'Hashing the password with a server challenge in JS is far more secure than just using HTTPS.'
It is wrong. Say what breaks — and say it before you turn the page.
Correct: The scheme offers little advantage over SSL and has shortcomings: the hashing JS arrives over the same untrusted network, and only one field is protected.
A student: what's the standard defense against eavesdropping?
Why: The scheme offers little advantage over SSL and has shortcomings: the hashing JS arrives over the same untrusted network, and only one field is protected. TLS is the standard for a reason.
Trap
A student: 'Hashing the password with a server challenge in JS is far more secure than just using HTTPS.'
Replace TLS with a JavaScript challenge-response scheme
Why: Wrong. The scheme offers little advantage over SSL and has shortcomings: the hashing JS arrives over the same untrusted network, and only one field is protected. TLS is the standard for a reason.
A student: what's the standard defense against eavesdropping?
Send the login over SSL/TLS (HTTPS)
Why: §14.2: TLS encrypts the whole channel — the password and the page that handles it. Challenge-response is a possible add-on, not a replacement, and gives little extra benefit.
Section
Part 3 · §14.3 the hardest vector
Concept
If the user's own machine is infected, the attacker sits inside the device. A keylogger records every keystroke — so it captures the password the moment the user types it, before any encryption ever happens.
This vector is very hard to defend: encryption protects the network, but the malware is upstream of the network, watching the input directly.
Concept
Some sites show a randomized on-screen keyboard — you click letters with the mouse instead of typing, so a keylogger captures no keystrokes.
But malware on the machine can take a screenshot at each click, recording exactly which key you pressed and where. The randomized layout buys nothing against malware that already owns the screen.
Intuition
The deeper lesson: once malware controls your device, it sees everything you see and do. Keystrokes, clicks, screen contents — all of it. There's no clever input gimmick that hides a secret from software running with your privileges.
So in this threat model, passwords are fundamentally insecure: a static secret you reveal to a compromised machine is a secret the attacker now has.
Ask yourself: what would make the stolen password useless to the attacker? (A second factor the malware can't replay — see 2FA next.)
Sorting
Sort into buckets
These are the pieces of L32 · Password Risks & Mitigations, out of order. Put each one back under the part of the lesson it belongs to.
Concept
If the password alone can't be kept secret, stop relying on it alone. Combine it with a second factor — something the attacker is unlikely to also have, like a one-time SMS code sent to the user's phone.
Two-factor authentication (2FA) — Requiring two independent factors to log in — typically something you KNOW (the password) plus something you HAVE (a phone receiving an SMS code, or an authenticator app / hardware token). Even a stolen password is then insufficient on its own.
Definition probe
Sort into buckets
Every line below is part of the definition of SSL/TLS (HTTPS) or of Two-factor authentication (2FA) — one or the other, never both. Put each where it belongs.
Trap
A student: 'Clicking a shuffled on-screen keyboard with the mouse beats keyloggers, so it's secure against malware.'
Rely on an on-screen keyboard against client-side malware
Why: Wrong. Malware that screenshots on each click records exactly which key you pressed. It dodges a KEYstroke logger, not a machine that already owns the screen.
A student: what actually helps once the machine is compromised?
Add a second factor (2FA) the malware can't also produce
Why: §14.3: if the device is owned, any password is exposed. The real defense is two-factor auth — a stolen password alone no longer logs the attacker in.
Section
Part 4 · §14.4 distributions & attack math
Concept
Online guessing means repeated login attempts. A smart attacker doesn't try random strings — they try the most likely passwords first, because real password choices are wildly non-uniform.
| Rank | Password |
|---|---|
| 1 | 123456 |
| 2 | password |
| 3 | 12345678 |
| 4 | qwerty |
| 5 | abc123 |
Pattern
Step through it
Step through §14.4 Smart attackers guess in order of likelihood one row at a time. What is driving the change, and what would the row after the last one be?
Concept
How fast does a likelihood-ordered dictionary pay off? Two benchmark numbers from large password studies:
| Dictionary size | Fraction of users cracked |
|---|---|
| Top 10 passwords | ≈ 1% |
| Top 2^20 (≈ 1 million) | ≈ 50% |
So just 10 guesses crack about 1 in 100 accounts, and a million-entry dictionary cracks about half of all users. The distribution's skew is the attacker's whole edge.
Comparison
Comparison matrix
From §14.4 The guessing distribution: refill the Fraction of users cracked column from what you know. The rest of the table is as it appeared.
| Dictionary size | Fraction of users cracked |
|---|---|
| Top 10 passwords | ≈ 1% |
| Top 2^20 (≈ 1 million) | ≈ 50% |
Ranking
Put in order
Put the moves of §14.4 How many guesses to crack half of all users? into the order they have to happen.
Why: These are the moves of the worked example in the order it makes them, and each one is set up by the one before it. The likelihood-ordered dictionary is steep at first then flattens; reaching half of all users takes about a million entries, far more than the 10 that already cover ~1%.
Worked example
Read the distribution: top-2^20 (~1,000,000) passwords ⇒ ≈ 50% of users
Why: The likelihood-ordered dictionary is steep at first then flattens; reaching half of all users takes about a million entries, far more than the 10 that already cover ~1%.
| Guesses tried | Cumulative users cracked |
|---|---|
| 10 | ≈ 1% |
| 2^20 ≈ 1,000,000 | ≈ 50% |
Convert 2^20 guesses on ONE account to wall-clock time at 1 guess/sec
Why: 2^20 ≈ 1,000,000 seconds; dividing by 86,400 seconds per day gives the elapsed time for a throttled targeted grind.
\[ \frac{2^{20}\ \text{guesses}}{1\ \text{guess/sec}} \approx 1{,}000{,}000\ \text{sec} \approx 11.6\ \text{days} \]
Verify: ≈ 11 days of nonstop wrong guesses against one account — loud and detectable
Why: §14.4: a million failed logins on a single account is trivially flagged, which is why TARGETED guessing is both slow and noisy — and why the cheap UNTARGETED spread is the bigger worry.
Notation
Annotate
From §14.4 How many guesses to crack half of all users? — read this one piece at a time. What is each part doing?
On: \( \frac{2^{20}\ \text{guesses}}{1\ \text{guess/sec}} \approx 1{,}000{,}000\ \text{sec} \approx 11.6\ \text{days} \)
Concept
Targeted attack — The attacker wants to break into ONE specific user's account. They must keep guessing against that single account until they succeed.
Untargeted attack — The attacker just wants to break into SOME account, any account. They can spread a few guesses across many accounts, cracking whichever is weakest.
This distinction decides which defenses work. Untargeted attacks exploit the ~1% who use a top-10 password; targeted attacks must grind the full distribution against one victim.
Intuition
If ~1% of users have a top-10 password, then across 100 accounts you expect about one of them to fall to those 10 guesses. So ~10 guesses × ~100 accounts ≈ 1000 attempts to crack one account — and crucially, that's only ~10 guesses per account.
Targeted is the opposite. To crack one chosen victim you may need the full ~2^20 dictionary. At a throttled 1 guess/second, 2^20 ≈ 1,000,000 guesses takes roughly 11 days — and a million failed logins on one account is noisy and detectable.
Ask yourself: which kind of attacker trips a 'too many wrong guesses on YOUR account' alarm? (Only the targeted one — the untargeted attacker barely knocks on each door.)
Ranking
Put in order
Put the moves of §14.4 The untargeted-attack workload into the order they have to happen.
Why: These are the moves of the worked example in the order it makes them, and each one is set up by the one before it. From the distribution: a likelihood-ordered top-10 dictionary cracks about 1% of users, so on average 1 of every 100 accounts has such a password.
Worked example
Use the top-10 hit rate of ≈ 1% (1 in 100 accounts)
Why: From the distribution: a likelihood-ordered top-10 dictionary cracks about 1% of users, so on average 1 of every 100 accounts has such a password.
Spread 10 guesses across ≈ 100 accounts to expect one success
Why: Trying the same 10 common passwords on 100 different accounts hits the ~1 expected weak account, with only 10 attempts per account.
| Quantity | Value | Why |
|---|---|---|
| Guesses per account | 10 | Top-10 dictionary |
| Accounts attacked | ≈ 100 | 1% hit rate ⇒ ~1 cracks |
| Total login attempts | ≈ 1000 | 10 × 100 |
| Per-account guess count | 10 | Far below any lockout threshold |
Verify: ~1000 attempts total, but only ~10 per account, cracks ~1 account
Why: §14.4: the cost is spread so thin per account (10 guesses) that no per-account limit is triggered — which is exactly why rate-limiting fails to stop untargeted attacks (Part 5).
Discrimination
Sort into buckets
Sort these by Value, from memory, without looking back at §14.4 The untargeted-attack workload. Telling them apart on the spot is the skill; the table is only where the answer happens to be written down.
Anomaly
Predict first
A student writes this, and it looks reasonable:
A student: 'If I lock an account after 5 bad guesses, I've stopped online guessing entirely.'
It is wrong. Say what breaks — and say it before you turn the page.
Correct: The untargeted attacker makes only ~10 guesses against EACH of ~100 accounts — well under any per-account threshold.
A student: what does per-account rate-limiting actually stop?
Why: The untargeted attacker makes only ~10 guesses against EACH of ~100 accounts — well under any per-account threshold. No single account ever hits the limit, yet one account still falls.
Trap
A student: 'If I lock an account after 5 bad guesses, I've stopped online guessing entirely.'
Assume per-account lockout stops the untargeted attacker
Why: Wrong. The untargeted attacker makes only ~10 guesses against EACH of ~100 accounts — well under any per-account threshold. No single account ever hits the limit, yet one account still falls.
A student: what does per-account rate-limiting actually stop?
Recognize lockout stops TARGETED attacks, not untargeted ones
Why: §14.4–14.5: lockout caps guesses against one account, crushing a targeted grind. The untargeted attacker spreads guesses thin across many accounts and slips under every per-account limit.
Section
Part 5 · §14.5 rate-limits, CAPTCHAs, rules
Concept
Cap the number of incorrect guesses — say 5 per hour, then lock or slow the account. This makes a targeted grind hopelessly slow: at 5 guesses/hour, the full 2^20 dictionary takes about 24 years.
But it has two problems: it introduces a denial-of-service risk (Mallory deliberately fails Bob's logins to lock him out), and it does NOT stop untargeted attacks. Only about 20% of major sites use it.
Concept
Require a CAPTCHA so automated guessing needs a human in the loop: making n guesses requires solving n−1 CAPTCHAs. The idea is to price out bulk automation.
But black-market solving services break this: they solve CAPTCHAs for about $1–2 per 1000 — roughly 0.1–0.2¢ each. And like lockout, CAPTCHAs do not stop untargeted attacks, which need very few guesses per account.
Explain it
Discussion prompt
Explain §14.5 CAPTCHAs to a student a year behind you. No notation, no jargon they have not met — and it still has to be true.
Hint: If your explanation needs a symbol they have never seen, you are describing the notation rather than the idea.
Answer:
Require a CAPTCHA so automated guessing needs a human in the loop: making n guesses requires solving n−1 CAPTCHAs. The idea is to price out bulk automation.
Concept
Hard requirements — minimum length, mandatory symbols — have poor usability, and users circumvent them (Password1!, then Password2!). They push the burden onto the user and often backfire.
Gentler nudges work better: a password-strength meter that shows weak/strong as you type measurably improves the passwords people choose, without forcing them.
Analogy
Discussion prompt
Explain §14.5 Password requirements vs nudges by analogy to something with no Computer Security in it at all — a queue, a recipe, a map, a bank balance, whatever fits. Then say where your analogy breaks.
Hint: An analogy that never breaks is not an analogy, it is the same idea wearing a hat. Find the seam — that is the part that is actually new.
Answer:
Hard requirements — minimum length, mandatory symbols — have poor usability, and users circumvent them (Password1!, then Password2!). They push the burden onto the user and often backfire.
Intuition
Every mitigation here is really answering 'how many guesses per account can the attacker afford?' Lockout and CAPTCHAs both attack per-account guess volume — which is exactly what the TARGETED attacker has lots of and the UNTARGETED attacker barely uses.
So both help against targeted attacks and both miss untargeted ones. The only mitigation that touches untargeted attacks is changing the distribution itself — getting users off the top-of-the-list passwords (strength meters, banning known-breached passwords).
Ask yourself: why doesn't a CAPTCHA stop the untargeted attacker? (They make ~10 guesses per account — a handful of cheap CAPTCHAs, at 0.1¢ each, is nothing.)
Counterexample
Discussion prompt
Ask yourself: why doesn't a CAPTCHA stop the untargeted attacker? (They make ~10 guesses per account — a handful of cheap CAPTCHAs, at 0.1¢ each, is nothing.)
That is stated as though it always holds. Do one of two things: produce a case where it fails, or say precisely what rules such a case out. "It just does" is not on the menu.
Hint: Hunt at the extremes first — zero, one, negative, empty, equal. If every extreme survives, the reason they survive is the proof.
Pattern
Predict first
The table runs: Lockout (5/hr) | Strong: 2^20 ⇒ ≈ 24 yrs | No effect (≈10/account) | DoS-by-lockout · CAPTCHA | Slows bulk guessing | No effect; ≈0.1¢ to solve | Solving farms; usability · Strength meter (nudge) | Helps (fewer weak pwds) | Helps (shrinks the ~1%) | Voluntary, partial
In §14.5 Compare mitigations on targeted vs untargeted, given the rows so far: what is the next one — the row where Mitigation is Hard requirements?
Correct: Hard requirements | Helps a little | Helps a little | Users circumvent them
| Mitigation | Targeted attack | Untargeted attack | Downside |
|---|---|---|---|
| Lockout (5/hr) | Strong: 2^20 ⇒ ≈ 24 yrs | No effect (≈10/account) | DoS-by-lockout |
| CAPTCHA | Slows bulk guessing | No effect; ≈0.1¢ to solve | Solving farms; usability |
| Strength meter (nudge) | Helps (fewer weak pwds) | Helps (shrinks the ~1%) | Voluntary, partial |
| Hard requirements | Helps a little | Helps a little | Users circumvent them |
Why: The relationship between the columns, not the individual numbers, is what generates the next row. Targeted attacks need many guesses per account; untargeted attacks need few.
Worked example
Score each mitigation by whether it raises per-account guessing cost
Why: Targeted attacks need many guesses per account; untargeted attacks need few. A mitigation only helps where it raises the cost the attacker actually pays.
| Mitigation | Targeted attack | Untargeted attack | Downside |
|---|---|---|---|
| Lockout (5/hr) | Strong: 2^20 ⇒ ≈ 24 yrs | No effect (≈10/account) | DoS-by-lockout |
| CAPTCHA | Slows bulk guessing | No effect; ≈0.1¢ to solve | Solving farms; usability |
| Strength meter (nudge) | Helps (fewer weak pwds) | Helps (shrinks the ~1%) | Voluntary, partial |
| Hard requirements | Helps a little | Helps a little | Users circumvent them |
Verify: only changing the password DISTRIBUTION dents untargeted attacks
Why: §14.5: lockout and CAPTCHAs cap per-account volume (good vs targeted) but the untargeted attacker barely guesses per account. Shrinking the pool of weak passwords (nudges) is what reaches the untargeted threat.
Trade off
Comparison matrix
From §14.5 Compare mitigations on targeted vs untargeted: every row here is a choice with a cost. Fill the Untargeted attack column, then say which row you would actually pick and what you give up for it.
| Mitigation | Targeted attack | Untargeted attack | Downside |
|---|---|---|---|
| Lockout (5/hr) | Strong: 2^20 ⇒ ≈ 24 yrs | No effect (≈10/account) | DoS-by-lockout |
| CAPTCHA | Slows bulk guessing | No effect; ≈0.1¢ to solve | Solving farms; usability |
| Strength meter (nudge) | Helps (fewer weak pwds) | Helps (shrinks the ~1%) | Voluntary, partial |
| Hard requirements | Helps a little | Helps a little | Users circumvent them |
Anomaly
Predict first
A student writes this, and it looks reasonable:
A student: 'Just lock the account after 5 bad guesses — pure upside, no cost.'
It is wrong. Say what breaks — and say it before you turn the page.
Correct: Mallory can deliberately submit wrong passwords for Bob's username to LOCK BOB OUT — a denial-of-service.
A student: what's the cost of aggressive lockout?
Why: Mallory can deliberately submit wrong passwords for Bob's username to LOCK BOB OUT — a denial-of-service. Lockout trades a guessing risk for an availability risk.
Trap
A student: 'Just lock the account after 5 bad guesses — pure upside, no cost.'
Deploy hard lockout with no thought to availability
Why: Wrong. Mallory can deliberately submit wrong passwords for Bob's username to LOCK BOB OUT — a denial-of-service. Lockout trades a guessing risk for an availability risk.
A student: what's the cost of aggressive lockout?
Weigh DoS-by-lockout; prefer slowdowns / backoff over hard locks
Why: §14.5: rate-limiting helps against targeted guessing but opens a DoS where an attacker locks out legitimate users. Real systems use throttling/backoff and account-recovery paths to manage that tradeoff.
Section
Part 6 · §14.6 motivating hashing
Concept
The last vector: the attacker breaches the server and steals the password database. If passwords are stored in cleartext, the breach instantly hands over every user's password — no cracking needed.
And because users reuse passwords (§14.1), the damage spreads beyond your site: the stolen password endangers each user's other accounts too.
Concept
In December 2009, the RockYou breach leaked about 32 million passwords — stored in cleartext. It became the canonical dataset for studying real password choices (it's where the top-password lists come from).
And this is not ancient history: an estimated 30–40% of sites still store passwords in cleartext (or in a recoverable form). The catastrophe is one breach away for a large fraction of the web.
Intuition
Imagine the attacker steals 32 million (email, password) pairs in cleartext. They don't stop at your site. They take those exact credentials to banks, email providers, and other services and try them — because people reuse.
This is credential stuffing (⊕): replaying breached username/password pairs across many sites. One weakly-defended site that stores cleartext can compromise accounts everywhere its users went.
Ask yourself: if you can't stop a determined attacker from eventually breaching the server, what should the server have stored so the loot is useless? (Something the attacker can't run backward into the password — a one-way hash.)
Worked example
Attacker breaches the server and dumps the password store
Why: Assume the server is eventually compromised — a realistic worst case. What the attacker walks away with depends entirely on HOW the passwords were stored.
| Storage | What the breach yields | Effect on user's OTHER sites |
|---|---|---|
| Cleartext | Every password, instantly | Immediate (reuse ⇒ stuffing) |
| Reversible encryption | Ciphertext + the nearby key ⇒ every password | Immediate (effectively cleartext) |
| One-way hash | Hashes only; must be cracked offline | Limited — strong passwords resist |
Verify: only one-way hashing makes the loot not directly usable
Why: §14.6: cleartext and reversible encryption both surrender the actual passwords on breach, cascading via reuse. A one-way hash forces the attacker into an offline crack — the foundation L33 builds on with salting and slow hashes.
Comparison
Comparison matrix
From §14.6 Trace a breach: cleartext vs hashed: refill the Effect on user's OTHER sites column from what you know. The rest of the table is as it appeared.
| Storage | What the breach yields | Effect on user's OTHER sites |
|---|---|---|
| Cleartext | Every password, instantly | Immediate (reuse ⇒ stuffing) |
| Reversible encryption | Ciphertext + the nearby key ⇒ every password | Immediate (effectively cleartext) |
| One-way hash | Hashes only; must be cracked offline | Limited — strong passwords resist |
Concept
The server doesn't actually need the password — it only needs to check a submitted one. So store a one-way hash of the password instead. On a breach, the attacker gets hashes, not passwords, and a one-way hash can't be run backward to recover them.
Password hashing (preview, L33) — Store H(password), not the password. At login, hash the submitted password and compare. Because H is one-way, a stolen database of hashes doesn't directly reveal the passwords. The full story — salting and slow hashes — is next lesson.
Anomaly
Predict first
A student writes this, and it looks reasonable:
A student: 'Don't store cleartext — encrypt the passwords with a key. Then a breach gives only ciphertext.'
It is wrong. Say what breaks — and say it before you turn the page.
Correct: Encryption is reversible: the server must hold the decryption key to check logins, so it's stored nearby.
A student: what should the server store instead?
Why: Encryption is reversible: the server must hold the decryption key to check logins, so it's stored nearby. An attacker who breaches the server usually grabs the key too — and decrypts everything.
Trap
A student: 'Don't store cleartext — encrypt the passwords with a key. Then a breach gives only ciphertext.'
Reversibly ENCRYPT the password database
Why: Wrong. Encryption is reversible: the server must hold the decryption key to check logins, so it's stored nearby. An attacker who breaches the server usually grabs the key too — and decrypts everything.
A student: what should the server store instead?
Store a ONE-WAY HASH of each password, not reversible ciphertext
Why: §14.6 → L33: the server only needs to CHECK passwords, not recover them. A one-way hash can't be inverted even with whatever the breach exposed — that's the point hashing (L33) builds on.
Two truths and a lie
Sort into buckets
Some of these hold up and some are the exact mistakes this lesson is built to prevent. Sort them.
Constraint
Discussion prompt
Run The password risk-and-mitigation playbook with this step confiscated:
Online guessing math: top-10 ⇒ ≈1% of users, top-2^20 ⇒ ≈50%. Untargeted = ~10 guesses × ~100 accounts ≈ 1000 attempts to crack one; targeted = ~2^20 at 1/sec ≈ 11 days and noisy.
Is it still possible? If it is, say what takes its place and what it costs you. If it is not, say exactly what that step was providing that nothing else does.
Hint: A step you can drop for free was never load-bearing. If you cannot drop it, name the thing that goes wrong the moment it is gone.
Answer:
Pattern
Edge cases
Discussion prompt
The password risk-and-mitigation playbook works on the cases you have just seen. Push it to the edge: what is the most degenerate input it still handles — empty, zero, one item, everything equal — and what is the first case where it stops being true? Name the case, not just "it breaks".
Hint: Try the smallest legal input, then the largest, then the one where two things collide. Methods are specified at their edges; the middle takes care of itself.
Answer:
Elimination
Eliminate the wrong options
Why does per-account lockout fail to stop this attacker, and what would actually help?
3 of these 4 are wrong. Strike them one at a time, and say what rules each one out before you strike the next. The survivor is the answer.
Survives elimination: B
Why: §14.4–14.5: this is an UNTARGETED attack. Spreading ~10 common-password guesses across ~100 accounts expects to crack ~1 account (top-10 ≈ 1% of users) while making only ~10 guesses per account — far under the 5-per-hour, well, under any per-account threshold the attacker simply paces below it. Per-account lockout and CAPTCHAs cap PER-ACCOUNT guessing volume, which is what a TARGETED attacker uses, not an untargeted one. The only thing that reaches an untargeted attack is changing the password distribution itself: nudging users off the most-common passwords with strength meters or banning known-breached passwords shrinks the ~1% the attacker is harvesting.
Check
A site locks any account after 5 failed logins per hour. An attacker just wants into SOME account, so they try the 10 most common passwords against each of 100 different accounts. Think it through before choosing.
Check your understanding
Why does per-account lockout fail to stop this attacker, and what would actually help?
Answer: B
Why: §14.4–14.5: this is an UNTARGETED attack. Spreading ~10 common-password guesses across ~100 accounts expects to crack ~1 account (top-10 ≈ 1% of users) while making only ~10 guesses per account — far under the 5-per-hour, well, under any per-account threshold the attacker simply paces below it. Per-account lockout and CAPTCHAs cap PER-ACCOUNT guessing volume, which is what a TARGETED attacker uses, not an untargeted one. The only thing that reaches an untargeted attack is changing the password distribution itself: nudging users off the most-common passwords with strength meters or banning known-breached passwords shrinks the ~1% the attacker is harvesting.
Concept
Concept
Concept
Connect it up
Draw it
One page, no notation unless you need it: draw how these connect — The Five Risk Vectors · Eavesdropping → SSL/TLS · Client-Side Malware → 2FA · Online Guessing — the Statistics · Mitigations for Online Guessing · Server Compromise → No Cleartext. Put an arrow wherever one of them is what makes another possible, and label the arrow with why.
Recap
You can now name the five password risk vectors and where each attacker sits, explain why TLS defends eavesdropping and why malware defeats any password (motivating 2FA), do the online-guessing math for targeted vs untargeted attacks, compare rate-limits / CAPTCHAs / nudges on each, and explain why storing cleartext is catastrophic — motivating hashing in L33.
| Idea | § | The one-line version |
|---|---|---|
| Five risk vectors | 14.1 | Guessing, phishing, eavesdrop, malware, server — one defense each |
| Eavesdropping | 14.2 | Send the login over SSL/TLS; challenge-response is weak |
| Client-side malware | 14.3 | Owned machine sees all; add 2FA (e.g. SMS code) |
| Guessing stats | 14.4 | Top-10 ≈ 1%, top-2^20 ≈ 50%; untargeted ~1000 attempts |
| Targeted vs untargeted | 14.4 | Lockout ⇒ 2^20 at 5/hr ≈ 24 yrs; untargeted slips under it |
| Mitigations | 14.5 | Rate-limit/CAPTCHA hit targeted only; lockout risks DoS; nudges help |
| Server compromise | 14.6 | RockYou 32M cleartext; reuse cascades — store a HASH (L33) |
Want this taught 1-on-1? Alexander tutors Computer Security — $55/session, free consultation.