Lecture 17: User Authentication

What this lecture covers

This lecture asks whether anything beats passwords for authenticating users, working through how password systems are implemented and attacked in practice, then applying a structured framework from the assigned paper to compare passwords against biometrics and hardware tokens like the CAP reader. It follows the course's earlier work on hashing and cryptography by applying those tools to a concrete, everyday problem: proving who you are to a server.

The lecture sits alongside the course's other applied-security case studies and builds toward a general lesson about system design: security properties alone rarely determine which scheme gets adopted. After watching, you should be able to explain how password hashing, salting, and challenge-response protocols defend against different attacks, and evaluate an authentication scheme along usability, deployability, and security axes rather than security alone.

Key ideas

• Password storage evolution: naive plaintext tables give way to hashed passwords, then to salted hashes, and finally to deliberately expensive key derivation functions, each closing a specific attack.
• Rainbow tables: precomputed password-to-hash mappings let an attacker amortize expensive hashing across many stolen databases; per-user salts defeat this by making each hash unique even for identical passwords.
• Skewed password distributions: because real passwords cluster around a small set of common choices, attackers can recover a large fraction of a stolen database by testing only the most popular passwords, even against expensive hash functions.
• Encryption and hashing alone don't authenticate the recipient: sending a password or its hash over an encrypted channel is useless if the client hasn't verified who is on the other end, since a man-in-the-middle can simply relay it.
• Challenge-response protocols: the server sends a random challenge that the client hashes together with the password, so a network observer or malicious server learns nothing usable without inverting the hash.
• Anti-hammering defenses: rate limits and timeouts on failed login attempts matter because passwords have low entropy (roughly 10 to 20 bits) and are easy to guess quickly without them.
• The paper's evaluation framework: authentication schemes are scored on usability (e.g., easy to learn, scalable, easy recovery), deployability (e.g., server/browser compatible, accessible), and security (e.g., resilient to observation, throttled/unthrottled guessing, phishing) properties, without assigning them relative weights.
• No scheme dominates: passwords, biometrics, and hardware tokens like the CAP reader each score well on some axes and poorly on others; the CAP reader nearly sweeps the security category but is rarely used because of its usability and deployability costs.

Walkthrough

From plaintext to salted, expensive hashes (2:02)

The lecture starts from the simplest password scheme, a server table mapping usernames to plaintext passwords, and shows why it fails if the server is compromised. It then layers on defenses: storing hashes instead of plaintext, using deliberately slow key derivation functions like PBKDF2 or bcrypt to slow down guessing, and adding a per-user salt to defeat precomputed rainbow tables. Throughout, it stresses that skewed real-world password distributions let attackers recover a large share of accounts even against these defenses.

Transmitting passwords safely (12:09)

This section examines how a password should be sent from client to server, showing that sending it in the clear, over an encrypted channel, or as a hash are all insufficient on their own if the client cannot verify it is talking to the real server. It introduces challenge-response authentication, where the server issues a random challenge and the client returns a hash combining the challenge and password, and discusses why letting the client also contribute randomness strengthens the scheme against a malicious or compromised server.

Guessing defenses and password entropy in practice (20:18)

The lecture covers anti-hammering techniques such as rate limiting and lockout timeouts, then explains why common password formatting rules (requiring punctuation, mixed case, and so on) do little against a sophisticated attacker, since users satisfy these rules in predictable ways. It references the "Telepathwords" tool as a demonstration of how predictable user password choices really are.

Offline guessing and password recovery (28:24)

Using Kerberos as an example, the lecture explains offline guessing attacks, where an attacker who intercepts a server's encrypted response can repeatedly guess keys and check whether the decrypted result looks well-formed, and how Kerberos V5 added a timestamp to close this hole. It then turns to password recovery, showing that an authentication scheme's real strength is the minimum of the password's entropy and the recovery question's entropy, citing the Sarah Palin email breach as an example of weak, publicly guessable recovery questions.

A framework for comparing authentication schemes (36:31)

The lecture introduces the paper's three evaluation categories: usability, deployability, and security, each broken into specific yes/no/quasi-yes properties. It applies these systematically to passwords, showing they score well on usability and deployability (since users and servers already know how to use them) but poorly on several security properties, including resistance to unthrottled guessing and to leaks propagating across services that share reused passwords.

Biometrics and the CAP reader (52:48)

The same framework is applied to biometrics, revealing that their effective entropy (roughly 12 to 20 bits depending on the modality) is not much better than passwords, and that they fail badly on recovery since a compromised fingerprint or iris scan cannot be reissued. The lecture then covers the CAP reader, a hardware device for one-time transaction codes, which scores near-perfectly on every security property but is rarely deployed because of its cost, inconvenience, and lack of browser or server compatibility. It closes with multi-factor authentication as a practical middle ground, combining different modalities (something you know, have, and are), and notes the tradeoff that users often weaken one factor when given a second.

Before you watch

• Review the course's earlier lectures on hash functions and encrypted communication, since password storage and transmission build directly on those concepts.
• Familiarity with basic protocol notation (client, server, challenge, shared secret) from earlier lectures will help with the challenge-response walkthrough.

Check your understanding

1. Why does salting a password hash defeat rainbow table attacks even though the salt is stored in plaintext on the server?
2. Why are encryption and hashing insufficient on their own to protect a password in transit, and what does a challenge-response protocol add?
3. Why do common password formatting requirements (mixed case, punctuation) often fail to meaningfully increase resistance to a sophisticated dictionary attacker?
4. According to the paper's framework, why do biometrics score poorly on "easy recovery" even though they score well on "nothing to carry"?
5. Why does the CAP reader score almost perfectly on the security category but remain rarely used in practice, and what does this suggest about how authentication schemes get adopted?