Lesson map
Lesson 19 published. Map, example, EX055.
flowchart TD
N0["Learning outcomes"]
N1["19.1 Comparing methods"]
N2["19.2 Cryptography users never see"]
N3["19.3 Rolling out with users"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX055"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["19.1 Comparing methods"]
N2["19.2 Cryptography users never see"]
N3["19.3 Rolling out with users"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX055"]
[Learning outcomes]
|
v
[19.1 Comparing methods]
|
v
[19.2 Cryptography users never see]
|
v
[19.3 Rolling out with users]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX055]
Learning outcomes
You will (1) compare authentication methods by usability and security; (2) explain why phishing-resistant authentication helps people; (3) plan an authentication rollout with users.
19.1 Comparing methods
Aiko compares authentication options for Greyford: passwords, text message codes, app approvals, app codes and security keys. She assesses each for phishing resistance, speed, cost and failure modes. Passwords are easy to phish and often reused. Text codes can be intercepted or phished in real time. App approvals can be abused by repeated prompts until a tired user accepts. Security keys resist phishing because they use cryptography tied to the genuine site, and they are quick once staff learn them. She summarises the comparison in one table.
19.2 Cryptography users never see
Aiko explains to staff that a security key holds a private key that never leaves the device. When signing in, the site sends a challenge, the key signs it, and the site checks the signature with the matching public key. The key also checks the site's identity, so a fake site receives nothing useful. Staff do not need to understand this to benefit; they only need to touch the key. Good cryptographic design hides complexity while removing a judgement users were bad at making.
19.3 Rolling out with users
Aiko plans a rollout: pilot with twenty volunteers, collect problems, issue two keys per person with one stored safely, provide a quick recovery route at depots and train staff in five minutes using a short video. She avoids text message codes as fallback because they would reintroduce phishing risk. She schedules the rollout outside winter, when burst pipes keep field staff busiest. Planning around people's work is as important as choosing the right technology. She also arranges for the pilot volunteers to act as local helpers in each depot, since colleagues often prefer to ask a peer before calling the help desk.
Worked example
Aiko compares five authentication methods, explains security keys in plain terms and plans a staged rollout with spares, recovery and seasonal timing.
Synthetic case. The rollout plan is synthetic.
Errors and limits
Security keys need replacement logistics. Some systems may not support them yet.
Exercises
- EX055 — Prompt abuse. How can app approvals be abused?
Show marking criteria
Rubric: 3 = repeated prompts until a tired user accepts;; 2 = prompt fatigue;; 1 = vague;; 0 = none. - EX056 — Key and fake site. Why does a fake site get nothing useful from a security key?
Show marking criteria
Rubric: 3 = the key checks the site's identity before signing;; 2 = origin check;; 1 = vague;; 0 = none. - EX057 — No SMS fallback. Why avoid text codes as fallback?
Show marking criteria
Rubric: 3 = they would reintroduce phishing risk;; 2 = phishing;; 1 = cost;; 0 = none.
Synthesis
Phishing-resistant authentication removes a hard judgement from people, if rollout respects how they work.
Continue studying — chapter 19 of 50
← Chapter 18 (draft) · Course chapter index · Chapter 20 (draft) →