What Each Kind of Proof Actually Resists
Last timeThree Questions, Often Confused
Passwords, emailed codes, authenticator apps and hardware keys are not stronger and weaker versions of one thing. Each resists a different attack and assumes something different.
Judging a proof by the attack
The usual way of talking about sign-in methods puts them on a line from weak
to strong. It is the wrong shape. Each method resists some attacks
completely and others not at all, and knowing which is which is more useful
than a ranking.
Four attacks cover nearly everything.
Guessing, where somebody tries values until one works, either against one
account or against millions of accounts with one common password.
Reuse, where a password leaked from an unrelated site is tried against
yours. The user did nothing wrong at your site and your site did nothing
wrong either.
Interception, where the proof is read in transit or read out of a log or a
screenshot.
And handing it over, where a convincing fake site asks the user for the
proof and they supply it, because it looks exactly like signing in. This is
the one that produces most of the real losses, and it is the one most
methods do nothing about.
| resists guessing | resists a leaked passwor | resists interception | resists a convincing fak | |
|---|---|---|---|---|
| a short password | 0 | 0 | 0 | 0 |
| a long unique password | 1 | 0 | 0 | 0 |
| password plus emailed co | 1 | 1 | 0 | 0 |
| password plus app code | 1 | 1 | 1 | 0 |
| password plus push appro | 1 | 1 | 1 | 0 |
| a hardware key | 1 | 1 | 1 | 1 |
| a passkey on the device | 1 | 1 | 1 | 1 |
A secret the user remembers
A password resists guessing, and only if it is long. The arithmetic is worth
stating because it is the only part of this that behaves well.
- number of possible values
- characters available in each position
- length of the secret
Against everything else it offers nothing, and the gap is not technical, it
is behavioural. A password is only unique to your site if the user made it
unique, and most people do not. So a leak anywhere becomes a leak
everywhere, and the attacker does not guess at all, they simply try the
known password with the known email address.
That assumption, that the user behaves in a way almost nobody behaves, is
the real weakness. It is also why the standard advice changed: long
passphrases rather than enforced symbol classes, a check against known
leaked passwords at the point of setting one, and no routine expiry, since
forced rotation produces predictable variations rather than new secrets.
Three things are your responsibility on the storage side, and they belong in
a different course on how a password is stored. Here it is enough to say
that the password must never be recoverable from what you hold, which rules
out encrypting it and rules out any design where somebody can be emailed
their existing password.
The lesson stops here
5 more paragraphs to go
You have read the opening. The rest of the argument, the problems that check whether it landed, and the lines worth keeping at the end all come with a plan.
The first lesson of every course in the library reads the whole way through, free, so you can see exactly what the rest of them are.
See the planThe contentsThis is the reading half
Starting the course gives you your own copy of it. Every idea on every page has problems standing under it, marked with a reason rather than a tick, and any sentence you do not believe can be opened and argued with. None of that can happen on a page nobody owns.
The contents