Passwords, and the ladder above them

You have a security plan from lesson 1, and on it there is almost certainly an email account. Look at where you ranked it.

Most people rank it below their bank. It's not below their bank. It's the way back into their bank, and into everything else they own, and this lesson is partly about why that is the sentence that matters.

But start somewhere more uncomfortable.

Most people who do that exercise find between three and a dozen. The number isn't the point. The third question is, and the rest of this lesson is an argument about why.

What the attacker actually does

Almost everything people believe about passwords comes from imagining the wrong attack.

The picture in most people's heads is somebody sitting at a login page, trying guesses. Your password is Tiger1987, they try password, then 123456, then eventually they get there, and so a cleverer password with a symbol in it buys you time.

That isn't what happens, and the reason is worth having, because it is what makes the real attack work.

Services do limit repeated failures against one account. So an attacker does not make thousands of attempts against you. They make one or two attempts against each of a hundred thousand accounts, from many different addresses, and every individual attempt looks like an ordinary person getting their password slightly wrong. There is nothing for a rate limit to catch.

The real one goes like this.

Somewhere, a company you signed up to in 2014 was breached. Their list of addresses and passwords is published. Your address is on it, with whatever you used there.

Somebody takes that list, points a program at two hundred other services, and tries every pair at machine speed. They aren't guessing. They already have your password. They are just finding out where else it works.

This has a name, credential stuffing, and once you've got it in your head everything else in this lesson stops being a list of rules and becomes obvious.

What the guidance actually says

Advice on this changed, and it changed at the source rather than in the popular press, which is why the popular version is still the old one. So what follows is the current version with its section numbers, because the point of a section number is that you can go and check it yourself.

The United States standard is NIST Special Publication 800-63B-4, final in August 2025.¹ One thing to know before quoting it at anybody: revision 4 renumbered the password section from 5.1.1.2 to 3.1.1.2, and raised the length floor, so an article quoting "NIST says eight characters" as the rule for an ordinary password is quoting the previous revision. Eight is still the floor, but only for a password used inside multi-factor authentication, which is a different case.

It is written in a deliberate language of SHALL and SHOULD, where SHALL is a requirement and SHOULD is a strong recommendation. Here is what §3.1.1.2 now requires of a service, in that language:¹

• Length. Verifiers and CSPs SHALL require a password used as a single factor to be a minimum of 15 characters. One used only as part of multi-factor authentication MAY be shorter and SHALL be at least eight.
• Maximum. Verifiers SHOULD permit at least 64 characters.
• Composition. Verifiers SHALL NOT impose other composition rules, for example requiring mixtures of character types.
• Rotation. Verifiers SHALL NOT require subscribers to change passwords periodically. They SHALL force a change on evidence that the authenticator has been compromised.
• Hints. Verifiers SHALL NOT permit a hint that an unauthenticated claimant can reach.
• Security questions. Verifiers and CSPs SHALL NOT prompt subscribers to use knowledge-based authentication or security questions when choosing passwords. NIST's own example is "What was the name of your first pet?" Read that last clause, because it is scoped and this lesson comes back to it.
• Blocklists. When processing a request to establish or change a password, verifiers SHALL compare it against a blocklist that contains known commonly used, expected, or compromised passwords, and on a match SHALL require a different one and SHALL give the reason for the rejection. NIST says that list may hold passwords from previous breaches, dictionary words, and context-specific words such as the name of the service or your username.
• Password managers. Verifiers SHALL allow password managers and autofill, and SHOULD permit pasting.

A "verifier" is the service checking your password, a "CSP" is whoever issued you the account, and a "claimant" is somebody who has not proved who they are yet. That is the document's vocabulary and it is worth having, because the requirements are written about what services must do rather than about what you must do.

Most of that list falls out of the picture in the last section, and two lines of it are about a different attacker. Take the first group.

Composition rules defend against somebody guessing at the login page, which is not what happens, and they cost real usability, so they go. Rotation defends against nothing measurable and costs a great deal, so it goes. Blocklists defend against exactly the attack that does happen, so they come in. And length goes up because of the offline case in the next paragraph.

But long is necessary and it is not sufficient, and it is important that removing composition rules did not leave you with "fifteen characters of anything". A memorable line from a song is fifteen characters of dictionary words, and dictionary words are on the blocklist by name. The blocklist is the rule that catches the long-but-guessable password, which is why it is not simply an anti-breach measure. Use something a manager generated, or words chosen at random rather than by you.

And the two lines about a different attacker. Hints and security questions are not about a machine replaying lists at all. They defend against a person who knows facts about you, and the lesson comes back to them at the end, because that is where they actually bite.

And notice the last four words of the blocklist rule. The service has to tell you why it refused. That is not politeness. If your password was refused because it appears in known breach data, the useful thing you have learned is not about this account. It is about every other account where you used it.

Why the expiry advice was withdrawn

This is the reversal people find hardest, so take it from the body that made it first. The UK's National Cyber Security Centre, which reversed this advice years before NIST's 2025 revision caught up with it, published a piece on forcing regular password expiry, and its argument is behavioural rather than mathematical.²

When you force a change, four things happen. The new password resembles the old one, because people increment. It may have been used elsewhere already. It is more likely to be written down. And it is more likely to be forgotten, which means support calls and reset flows, which are themselves a way in.

NCSC's conclusion is that the more often users are forced to change passwords, the greater the overall vulnerability.²

That's a claim about people rather than about cryptography, and it is worth saying so plainly rather than dressing it up as a mathematical result.

The honest part: this is not a settled experiment

The rotation guidance is the official position of NIST, NCSC and CISA, and this lesson teaches it as the guidance. But there is a live minority, it is not stupid, and you should hear it at its strongest rather than as a strawman.

The case for expiry goes like this. A password that has been compromised without anybody noticing stays useful to the attacker indefinitely. Expiry puts a ceiling on that: whatever else it costs, it bounds the lifetime of a compromise nobody detected. And NIST's replacement trigger, "force a change on evidence of compromise", assumes the organisation has a way of detecting compromise, which a great many do not.

That's a real argument and it is mostly held by people in compliance and audit who are rarely writing papers about it.

What NCSC does with it is worth noticing carefully, because it isn't a refutation. NCSC acknowledges the intuitive case and calls it oversimplified.² It doesn't present a trial showing expiry makes things worse.

What would settle it is a field study measuring actual compromise rates under each policy at scale, and nobody has run one.

So the accurate summary is this. The guidance is clear, it is unanimous across the major bodies, and the evidence behind it is behavioural reasoning rather than a controlled experiment. That's a good reason to follow it and a bad reason to be smug about it.

One practical warning. Plenty of employers still enforce rotation and composition rules, because their compliance regime requires it. "The guidance says otherwise" is not an answer your IT department can act on, and this lesson isn't asking you to have that fight. Use a manager, make each one long and unique, and let the policy do what it does.

The ladder above the password

Everything so far has been about the password. Now the more important half.

A second factor is something required in addition to the password, so that knowing the password is not enough. The popular framing is a switch: two-factor is on or it is off, and on is safe. That framing's wrong in both directions, and it is more useful to think about a ladder.

Rung zero: nothing. The password is the whole defence. A breach anywhere you reused it opens this.

Rung one: a code by text message. The service texts you a number and you type it in.

Rung two: a code from an authenticator app. Your phone generates a number that changes every thirty seconds, with no message sent anywhere. When you turn this on, the service will offer you backup or recovery codes. Save them. A code-generating app lives on one device, and the commonest way people lose an account is not an attacker but a lost or wiped phone with nothing written down.

Rung three: a passkey or a security key. Something on your device, or a small physical key, that proves who you are to the site without you ever seeing or typing a secret.

This is what each one stops, before the two sections that argue about it.

Read the third column downwards. The first two rungs share a weakness and the third does not, and that single column is the argument of the next two sections.

What the first rung stops, and why it is the biggest step

An SMS code stops the attack from the top of this lesson dead. The program replaying breached passwords across two hundred services has your password and no phone. It fails.

It's also the rung with the most criticism attached to it, and the criticism is true.

NIST designates out-of-band authentication over the public telephone network "restricted" in §3.1.3.3, and says verifiers SHOULD consider risk indicators such as device swap, SIM change and number porting before using it.¹ That last phrase is the mechanism: your phone number is not attached to your phone. It's a record at a telephone company, and somebody who persuades that company to move it has your codes.

CISA excludes SMS from phishing-resistant authentication, along with email links, authenticator app codes and push notifications, even push with number matching.³ Phishing-resistant is a specific property and not a compliment: it means the method cannot be handed to a fake site by a person who has been convinced to hand it over. Only two approaches meet that bar, and they are the third rung, which is the next section.

How often does the number-moving attack happen? The FBI's complaint centre recorded 982 SIM-swap complaints and about $26.0 million in reported US losses in 2024, against 1,611 complaints and over $68 million in 2021.⁴

Read those as what they are: reported US complaints, which is a floor rather than a measure of how often it happens. They are real money and real people.

The comparison worth drawing is qualitative rather than numerical. A SIM swap needs a person working on one target, talking a phone company into something. Credential stuffing needs nobody at all, runs against everybody at once, and is already running.

One caution before you take rung one, though, and it cuts the other way. On many services a phone number is itself a login route or a recovery route. Adding SMS is then not purely additive: it can become the weakest way in rather than an extra lock, which is the section at the end of this lesson arriving early.

Which gives the sentence this whole ladder exists to support:

For most people's threat model, the step from nothing to SMS is larger than the step from SMS to a security key.

That comparison is this course's reading of the two sources above, not a claim either of them makes. NIST and CISA say where SMS sits; the complaint figures say something about how often the telephone attack is reported. Nobody has put a number on the two steps, and if somebody does and it disagrees with that sentence, believe them and not me.

The reasoning behind it is the section you have just read. Both steps are worth taking. But if you've twenty accounts with no second factor and you spend your afternoon deciding which authenticator app is best, you have optimised the second step and skipped the first.

What the third rung stops that the first two do not

Now the attack the first two rungs do not survive, and it is the one from lesson 8.

You are sent to a convincing fake login page. You type your password. The fake page asks for your code, because of course it does. You read the code off your phone and type it. The fake page passes both straight to the real site, inside the thirty seconds the code is good for, and it is in.

A code you can read is a code you can be persuaded to hand over. That is true of an SMS code and equally true of an authenticator app code, which is why CISA puts both outside the bar.

A passkey or a security key is different in kind rather than in strength. It's tied to the site's actual address, and it simply will not answer a different one. There's no code for you to read out, so there's nothing for a convincing page to ask you for. The fake site asks, and the key does not respond, and you find out something is wrong by the thing not working.

Section 3.1.1 of the NIST document states it flatly: passwords are not phishing-resistant.¹ The ladder is the response to that sentence.

Adoption is still early. Okta's 2025 report puts workforce multi-factor adoption at about 70% as of January 2025, and phishing-resistant authenticator use at 14.0% of users, up from 8.6% a year earlier.³

Two cautions on those, both mine. They are workforce figures from one vendor's customer base, so they describe organisations that manage sign-in for a living rather than consumers, and 8.6% to 14.0% is two points and not a curve. What they will support is the modest claim, which is that the top rung is early even where you would expect it earliest.

The way back in, which is the part everybody skips

A long password. A second factor. And then the "forgot password" link, which is a second front door with different locks.

Most consumer security advice stops before this, which is why this section exists.

The recovery path is a way into the account. If it is weaker than the front door, it is the door. And it very often is:

It sends a code to an email address. Which is fine, if that email account's at least as well defended as this one. This is why your email ranks first on the plan, above your bank: it is the recovery path for the bank.

It asks a security question. Your mother's maiden name. Your first school. Your first pet.

Be precise about what the guidance says here, because it is narrower than it is usually quoted. NIST §3.1.1.2 forbids verifiers to prompt for knowledge-based authentication when choosing passwords.¹ It is a rule about password selection, and a recovery flow is a different moment.

But the reason carries straight across, and that is this course's own argument rather than NIST's. The answers are facts about you, and facts about you are not secrets. Anybody who knows where you grew up can answer them, which for a great many people includes somebody they have specifically stopped trusting. A standards body forbidding these at password selection while services keep them on the recovery path is a gap in coverage, not a judgement that they are fine there.

It sends a code to a phone number. Which is rung one, whatever rung your front door reached.

It falls back to a human. Support staff, whose job is to be helpful to people who are locked out and upset, which is precisely the state an attacker will perform.

So the rule is simple and almost nobody applies it: climb the ladder on the recovery path too, or at least find out how high it goes. If a service lets you remove the security questions, remove them. If it makes you keep them, put a long random answer in your manager rather than the true one, because there is no rule saying the answer has to be true.

Be honest about what that buys, though. It's a good answer against anybody researching you, and it does much less at a telephone support desk, where you cannot easily read out thirty random characters and where staff are trained to be helpful to people who are locked out. That is the next bullet's problem and it is not solved by this one.

What people get wrong

"Complex beats long." Complexity defends against guessing. Nobody's guessing. Current guidance, in its August 2025 revision, explicitly forbids services from requiring composition rules and requires a fifteen-character minimum for a single-factor password.¹

"Changing passwords regularly is good practice." Withdrawn, by NIST in the 2025 revision and by NCSC before that, and the reasoning is behavioural: forced changes produce predictable new passwords, more reuse, more writing down and more forgetting.¹² The minority case for expiry is in the section above and is worth knowing rather than dismissing.

"A password manager is a single point of failure, so it is worse." The concentration is real, and pretending otherwise is why this argument never gets anywhere. Everything is behind one password, and if that one is lost, a great deal goes with it. Say that plainly, first.

Then the comparison that matters. The alternative is not "memorised unique passwords for forty accounts", because almost nobody manages it. The realistic alternative is reuse, and reuse converts any single breach into a compromise of everything, which is the same failure mode with a much higher probability. Current guidance requires services to permit managers and autofill, which is the standards bodies saying the same thing.¹

"The browser's built-in one doesn't count." It counts. It's a real option, and presenting it as a compromise does more harm than good, because the manager somebody actually uses beats the better one they downloaded and abandoned. That last sentence is this course's judgement, on interview evidence it has read only in summary, and it is worth marking as such. If a separate app suits you, use it. If the one already in your browser is what you'll actually use, that's the right answer for you.

"Two-factor means I am safe." Phishing-resistant is a specific technical property and app codes do not have it. Everything below rung three can be relayed by a convincing page in real time.³

"SMS is useless, experts say it's broken." Experts say it is restricted and outside the phishing-resistant bar, and both are true.¹³ They are not saying it is worthless. It stops the automated attack that reaches almost everybody, and it is enormously better than nothing. The ladder exists so that a true criticism of rung one does not send somebody back to rung zero.

Practice

Connections

Lesson 1 gave you the security plan, and the ranking it produced is what orders the five accounts above. If your plan put email below your bank, this lesson is the reason to move it.

Lesson 8 showed you a fake page with a perfect padlock. This lesson tells you what happens next when you type a password into one, and why only the top rung of the ladder survives it.

Lesson 9's expert list had three items and two of them were this lesson: a password manager and two-factor authentication. That list is the reason this material gets a lesson of its own rather than a paragraph.

Lesson 11 is where the attacker stops replaying lists and starts asking you directly. Everything here is defence against machinery. That one is about defence against a person, which is a different problem and needs a different kind of answer.

Lesson 13 asks what a service holds about you. The accounts you have just hardened are the ones whose answer matters most.

Go deeper

• NIST SP 800-63B-4, section 3.1.1.2, free, a US government work in the public domain. This is the primary source for most of this lesson. Read the section itself rather than an article about it, and notice how short it is. The value is in the SHALL and SHOULD language, which is precise in a way that summaries of it never are.
• NCSC, "The problems with forcing regular password expiry", free, under the Open Government Licence. Three or four screens, and the clearest short statement of a reversal that most of the world has still not caught up with.
• Have I Been Pwned, free. The exercise at the top of this lesson, and the one thing in this course that reliably changes somebody's behaviour on the day they do it.

Sources

1. NIST, Special Publication 800-63B-4, Digital Identity Guidelines: Authentication and Authenticator Management, final, August 2025, pages.nist.gov/800-63-4/sp800-63b.html. Sections 3.1.1, 3.1.1.2 and 3.1.3.3 fetched directly and read; the requirements above are quoted in the document's own SHALL and SHOULD language. Supplies the fifteen-character minimum for single-factor use and the eight-character minimum within multi-factor, the recommendation to permit at least 64, the prohibitions on composition rules and periodic rotation, the requirement to force a change on evidence of compromise, the prohibitions on reachable hints and on knowledge-based authentication (with "what was the name of your first pet?" as NIST's own example), the blocklist requirement including the requirement to give the reason for rejection, the requirement to allow password managers and autofill, the statement in 3.1.1 that passwords are not phishing-resistant, and the designation in 3.1.3.3 of out-of-band authentication over the public telephone network as restricted, naming device swap, SIM change and number porting. Revision 4 renumbered the password section from 5.1.1.2 to 3.1.1.2 and raised the length floor, which is why articles quoting "NIST says eight characters" for a single-factor password are quoting a superseded revision.
2. UK National Cyber Security Centre, "The problems with forcing regular password expiry", ncsc.gov.uk. Read in full. Supplies the four behavioural consequences of forced expiry (the new password resembles the old, may have been used elsewhere, is more likely to be written down, is more likely to be forgotten), the conclusion that more frequent forced changes increase overall vulnerability, and NCSC's own treatment of the intuitive case for expiry, which it acknowledges and calls oversimplified rather than refuting. The lesson's statement that the evidence is behavioural rather than a controlled trial follows from that and is this course's characterisation, not NCSC's.
3. CISA and the FIDO Alliance on phishing-resistant authentication, and Okta's 2025 Secure Sign-in Trends Report. Read at search-summary level; no primary document was opened. Supplies that CISA's guidance names FIDO/WebAuthn and PKI-based authentication as the only approaches meeting the phishing-resistant standard and places SMS codes, email links, authenticator app codes and push notifications including number matching outside it; and Okta's figures of about 70% workforce multi-factor adoption as of January 2025 and phishing-resistant authenticator use at 14.0% of users, up from 8.6% a year earlier. Because this is summary-level reading, the lesson uses these for the shape of the ladder and the direction of adoption and makes no finer claim from them.
4. FBI Internet Crime Complaint Center, complaint and loss figures for SIM swapping, as recorded in this course's research/SOURCES.md: 982 complaints and about $26.0 million in reported US losses in 2024, against 1,611 complaints and over $68 million in 2021. Used in preference to two other studies on this subject that the research identified and did not open, as the callout above says. The comparison the lesson draws from these figures, that SIM swapping is real and comparatively targeted next to automated credential stuffing, is this course's reading of them and not a claim made by the source.