Password Rules Are Mostly Wrong

16.0 What this chapter gives you#

1. You will be able to name the exact document, appendix and year that turned “one capital, one number, one symbol” from a rough estimate into a worldwide requirement, and explain the arithmetic inside it.
2. You will be able to state what Bill Burr actually said in August 2017, what he was and was not taking back, and which parts of the popular retelling are wrong.
3. You will be able to quote the current rules from NIST SP 800-63B revision 4 of July 2025 clause by clause, say which are SHALL and which are SHOULD, and name every clause that changed from the 2017 edition.
4. You will be able to give three independent pieces of evidence that forced password expiry makes passwords weaker, with authors, venues, years and figures.
5. You will be able to say where the numbers 8, 15 and 64 come from, which is a floor, which is now a requirement, and which is a ceiling you must be willing to accept.
6. You will be able to write a length check that counts Unicode code points rather than bytes, normalize a password before hashing, and say exactly what breaks when the normalization form changes underneath a live user base.
7. You will be able to specify a blocklist properly: what to load into it, how to match against it, how large it should be, and why past a certain size it stops helping.
8. You will be able to explain why password hints and security questions are both banned outright, naming the breach that settled the first and the study that settled the second.
9. You will be able to put a correct password policy and the policy most sites still run side by side, line by line, and defend every line of the correct one to an auditor.

Almost every password rule you have ever obeyed is wrong. Not old-fashioned, not merely annoying: wrong, in the specific sense that the organization which gave the world its most-cited justification for those rules formally withdrew that justification, published the opposite advice, and has since tightened the opposite advice further. The man who wrote the original appendix told a newspaper he regretted it. The British government’s security centre says the same thing in different words. Microsoft removed the best-known of the rules from its own recommended settings and called it obsolete. And yet, if you registered an account this morning, you were almost certainly asked for one capital letter, one digit and one symbol, in a box that silently refused to accept a space.

This chapter is the story of that gap, and it is a practical story rather than a scandal. The rules came from an honest attempt to answer a question nobody could answer properly: how strong is a password that a human chose? The attempt was a scoring scheme, written down in an appendix, hedged carefully by its author, and then read by thousands of engineers who needed a rule for a registration form. The scheme awarded bonus points to systems that forced a mixture of character types. Bonus points are a description; a registration form needs an instruction; and so the description became the instruction, and stayed the instruction for thirteen years after the evidence turned against it.

We are going to do three things. First, in plain words, we will follow the rule from the estimate that produced it to the login box you met this morning, and see what real people do when a rule tells them to change a password four times a year. Then we will pull apart the parts of that story that are too tidy, because the popular version of this retraction is itself wrong in several places and a practitioner who repeats it will be corrected in a meeting. Then we will state the current rules exactly, in the words the specification uses, with the section numbers and the dates, and finish by writing out a correct policy and the policy most sites still use, side by side, so you can hold your own registration form against both.

One boundary before we start. How a password is stored after it is chosen, salting, slow hashing, memory-hard functions, is the job of chapter 14, “Storing a Password”. How an attacker breaks a stolen file of them is chapter 15, “Cracking a Password”. What replaces a password when a password is not enough is chapter 17, “The One-Time Code”, and after that the chapters on passkeys. This chapter is only about the rules you impose at the moment a human chooses a secret, which is a smaller subject than the others and, as it turns out, the one that has been got wrong for longest.

The plain version#

A scoring sheet, not a rule book#

Imagine a national office that certifies locks. In 2004 it is asked a hard question by the government departments it serves: if we let citizens choose their own secret word instead of issuing one, how safe is that? Nobody can measure this properly, because it depends on what is in people’s heads. So an engineer at the office does the honest, useful thing. He writes an appendix that says, in effect: here is a rough way to score a secret word, use it to compare systems, and do not mistake it for a measurement.

The scoring sheet is simple enough to do on paper. The first letter of the word is worth four points. Each of the next seven letters is worth two points. Letters nine to twenty are worth one and a half points each. Anything beyond the twentieth letter is worth one point. The idea behind the falling scale is that people are predictable once they get going: the first letter of a word tells you little, but by the sixth letter you can often guess the rest, so later letters add less.

Then come two bonuses, and the bonuses are where the trouble starts. Add six points if the system forces the person to include both a capital letter and something that is not a letter. Add up to six more if the system checks the chosen word against a list of at least fifty thousand common words and rejects any match. The engineer is careful in his own text: he says the composition benefit is “probably modest”, he says forcing those characters actually shrinks the total number of possible words, and he says the dictionary bonus fades away for longer words and reaches nothing at twenty characters.

Read that as an engineer building a sign-up page in 2006. You have a scoring sheet from the national standards office. It gives you six points for free if you demand a capital and a symbol. Six points, on a scale where an eight-character word without any rules scores eighteen, is an enormous fraction. You add the rule. Every other engineer adds the rule. Within a few years there is not a login form in the world that does not demand a capital, a digit and a symbol, and no one remembers that the six points were one person’s cautious guess at how much a rule helps, published as an aid to comparison and hedged in the surrounding paragraphs.

Where “every ninety days” came from#

The same appendix does something else that looks harmless and is not. It treats how long a password stays in use as one ingredient in a sum. The reasoning is straightforward. An attacker who is guessing at a login screen can only make so many attempts a day. If the password is replaced before he has made enough attempts to have a real chance, he never gets there. So the appendix works examples: a password with about thirty points, an account that locks for a day after six wrong tries, a password replaced every two years, and it shows the attacker gets nowhere.

Notice what that arithmetic is really about. It is about the total number of guesses an attacker gets, and the password’s lifetime is only one of three ways to hold that number down. The other two are limiting how fast he can guess and rejecting weak words in the first place. But of the three, lifetime is the one that turns into a single number an auditor can put in a box and tick. Ninety days is a nice number. It fits a quarter. It appears in checklists, then in contracts, then in every corporate policy on earth, and nobody ever writes down the sum it was supposed to be part of.

The honest version: forcing a change on a schedule was never the recommendation of that appendix. The appendix used a password’s lifetime as an input to a calculation about guessing budgets, and its own worked examples used lifetimes of two years and ten years, not three months. The ninety-day rule arrived by a different route, through audit checklists and payment-industry rules, and simply borrowed the standards office’s authority on the way past.

What a person actually does when you make them change it#

Meet Anand Kulkarni, who administers the student records system at a college in Nagpur. His college’s policy is the one you already know: eight to twelve characters, at least one capital letter, at least one digit, at least one symbol from a short approved list, no spaces, changed every ninety days, and three security questions on file in case he is locked out. There is also a hint box on the change-password screen, in case he forgets.

Anand is not careless. He is busy, and he has to remember this password while walking between two buildings four times a day. In January he chooses “Sunita@01”, his wife’s name and a number. In April the system tells him his password has expired and he cannot reuse the last five. He chooses “Sunita@02”. In July, “Sunita@03”. By the following January he is on “Sunita@05” and has never once thought about the choice, because the policy trained him not to. The policy asked for a capital, a digit and a symbol; “Sunita@01” has all three; the policy has nothing further to say.

Now look at what the policy actually bought. Anand’s password is a common first name, a symbol that is the most popular of the approved symbols, and a two-digit counter. Anyone who has ever seen one of his passwords, an old backup, a phishing page, a shoulder glance, can guess the current one in a handful of tries, because the change rule taught him to edit rather than to replace. The ninety-day rule did not produce five independent secrets. It produced one secret with a serial number on the end. And the composition rule did not produce an unpredictable password; it produced a predictable shape, name plus symbol plus digits, which is exactly the shape every attacker’s guessing tool tries first.

That is the whole indictment in one example. The rules did not make Anand’s password strong. They told him precisely which narrow corner of the space of all passwords to stand in, and then made him shuffle his feet in that corner four times a year.

The office that wrote the rules took them back#

In 2017 two things happened within two months of each other.

In June, the same national standards office published the replacement for the old guidance. The new document did not soften the old rules. It reversed them, point by point, and the next section sets out what it asks for instead.

In August, a reporter at the Wall Street Journal tracked down the man who had written the old appendix. Bill Burr was seventy-two and retired. The article ran on the seventh of August 2017 under a headline that mocked the old rules by spelling “never mind” with digits and symbols. The line everyone remembers is his: “Much of what I did I now regret.” He said the scheme had been too complicated for most people to follow properly, and that it had been aimed at the wrong target.

So we have the unusual situation where the rule and its retraction come from the same address. That is the sentence to keep. The composition rules, the ninety-day expiry, the security questions and the hint boxes were not withdrawn by critics or by a rival camp. They were withdrawn by the body whose authority made them universal, and the replacement says the opposite, and it has said the opposite for nine years as of August 2026.

What the replacement actually asks for#

Stripped of specification language, the current rules are shorter than the old ones and easier to obey.

Make it long. Length is the lever; a longer password is harder to guess, no harder to type once, and costs nothing extra to store, because a stored password takes the same room whatever its length. Let people use anything they can type, including spaces, accented letters, and alphabets that are not the Latin one. Do not cut a password short, silently or otherwise. Do not tell people which kinds of characters to include; that instruction does not make a choice unpredictable, it only narrows its shape.

Check the password they picked against a list of passwords already known to be popular or already spilled in a public breach, and if it is on the list, say so plainly and ask for another. Then leave them alone. Do not expire it on a schedule. If you learn it has leaked, force a change immediately and say why. Finally, remove the two features that quietly hand the password to an attacker: the hint, which is a clue stored beside the secret and shown to whoever asks, and the security question, which is a second, weaker password with an answer a stranger can often look up.

The policy Anand should have had#

Under the correct rules, Anand’s screen would say something like this: your password must be at least fifteen characters; you may use up to sixty-four; anything you can type is allowed, including spaces; we will check it against a list of known-bad passwords; and once you have set it we will not ask you to change it again unless we have reason to think it has been exposed.

Anand types “sunita cooks at seven”. Twenty-one characters, four ordinary words and three spaces, no capital, no digit, no symbol. The old policy would have rejected it on five separate counts: too long for the twelve-character maximum, no capital, no digit, no symbol, and it contains spaces. The new policy accepts it, and it is far harder to guess than “Sunita@05”, because there is no template to follow: an attacker cannot enumerate “first name plus symbol plus two digits” and expect to find it. Anand can remember it, because it is a sentence about his life rather than a random string, and he will never have to invent another one on a schedule.

That is the plain version. The rules were a scoring sheet that got promoted to law, the promotion was withdrawn by the office that issued it, and the replacement is shorter, kinder and stronger. Everything after this point is either a place where that story is too tidy, or the exact wording you need in order to act on it.

Where the plain version stops being true#

Burr did not invent composition rules, and the appendix is not what most people think it is#

The retelling you will hear in meetings is that one man invented password complexity in 2003 and apologized in 2017. Both halves are too neat.

Composition and length rules are much older than 2003. In November 1979, in the Communications of the ACM, Robert Morris and Ken Thompson published “Password Security: A Case History”, describing the password system of Unix. They collected 3,289 passwords from real users and found that 2,831 of them, 86 per cent, fell into a handful of trivially searchable classes: single characters, three-letter strings, six lower-case letters, or words from an available dictionary. Their response was to change the program so that a user entering an all-one-case password shorter than six characters, or a mixed-character password shorter than five, was asked for a longer one, and to suggest that users be “urged (or forced) to use either longer passwords or passwords chosen from a larger character set”, or that the system choose passwords for them. That is a composition rule and a minimum length, in 1979, twenty-four years before the appendix.

In April 1985 the United States Department of Defense published CSC-STD-002-85, the Password Management Guideline, one of the “rainbow books”. It said passwords should be machine-generated rather than user-created, set a minimum of six characters, and stated that the maximum password lifetime “should not exceed one year”. It even gave the formula that everything since has been an argument about: the probability of a successful guess within a password’s life is the lifetime multiplied by the guess rate, divided by the size of the password space. So password ageing is from 1985 and its official maximum was one year, not ninety days.

What the 2004 appendix added was not the idea of rules. It added a number to the idea, and a number from a national standards body is what an engineer needs in order to justify a decision. That is why the appendix mattered so much, and it is also why the popular story is unfair to its author: he wrote an estimating aid, hedged it in his own text, and watched it become a global mandate.

The honest version: Bill Burr’s regret in 2017 was aimed at the whole family of advice he had helped make normal, including the composition scoring and the guidance around expiry. He did not claim to have invented the practice, and he was not the sole author of the document. Several people who worked on the modern replacement have pointed out publicly that the appendix was an entropy estimator, not a policy template, and that the world misread it. Both things are true at once: the misreading was the world’s, and the appendix made the misreading easy.

“NIST says eight characters” is now out of date#

For most of the last decade, the single most quoted line from the modern guidance was that a password must be at least eight characters. That line is still in the current document, but it no longer means what people quote it to mean, and repeating the old summary in 2026 will get you the wrong policy.

The 2025 revision splits the requirement in two. If a password is the only thing standing between the claimant and the account, the minimum is fifteen characters and it is a SHALL, the strongest word the document has. Eight survives only for passwords that are one factor inside a multi-factor arrangement, where something else is also being checked. So “the minimum is eight” is now true only of a system that has a second factor, and false of the ordinary password-only login that most of the web still runs. When someone tells you NIST allows eight, the correct reply is to ask whether the password is being used on its own.

Expiry is not always wrong, and one large standard still requires it#

The plain version says do not expire passwords. The precise version is that you must not expire them on a schedule for ordinary user accounts, and you must expire them immediately when you have evidence of compromise. There are also cases where scheduled rotation is still the least bad option, and pretending otherwise will make you look naive.

A password shared by several people, for example an account that three technicians use on a piece of equipment, has no owner to notify and no reliable way to detect misuse, and people leave the team. A credential embedded in a system with no way to detect its use, and no second factor, is in a similar position. In both cases rotation is a crude substitute for the thing you actually want, which is one identity per human and a way to revoke it. The chapter on machine identities, chapter 47, treats the equivalent problem for software credentials.

There is also a hard commercial fact. As of August 2026, the Payment Card Industry Data Security Standard, version 4.0.1, still requires in its requirement 8.3.9 that where a password is the only authentication factor for user access, either passwords are changed at least once every ninety days, or the security posture of accounts is dynamically analysed and access decisions made in real time. [UNVERIFIED: the exact wording of PCI DSS 4.0.1 requirements 8.3.6 and 8.3.9, taken from assessor summaries because the standard itself sits behind a licence acceptance] The second branch is the modern one and it is what the standard added so that organizations could stop rotating, but it demands machinery most organizations do not have. So a payments business can be simultaneously compliant with PCI DSS and out of step with the current NIST guidance, and its assessor will not care what NIST says.

Where experts disagree, they disagree narrowly. Nobody serious now argues that scheduled expiry improves the security of ordinary user passwords. The live argument is about shared and unattended credentials, where some practitioners hold that rotation still buys something against a stolen credential nobody has noticed, and others hold that it merely produces predictable variants and a false sense of control.

A blocklist is not free, and a bigger one is not better#

The plain version says check the password against a list of bad ones. That is right, and it is the single most valuable rule in the modern set, but three practical truths hide behind it.

The first is that a blocklist rejects real people. Every rejection is a person standing at a form being told no, and if your matching is aggressive, some of those people are being told no about a password that was actually fine. Aggressive matching means checking not just the whole password but pieces of it, which rejects “mypasswordisgood” because it contains “password”. Research on this has been done properly and the aggressive settings do produce stronger passwords, at a real cost in frustration and abandoned sign-ups.

The second is that the list stops helping after a certain size, and the current guidance says so in as many words: excessively large blocklists are of little incremental security benefit, because the blocklist defends against online guessing, and online guessing is already limited by the rule that caps failed attempts. A list of a few hundred thousand entries covers what an attacker could try before being throttled. Loading half a billion entries makes the check slower and the rejections more annoying without changing the outcome of the attack it defends against.

The third is that checking against a breach list without leaking the password is a problem in itself, solved by sending only a short prefix of the password’s hash and getting back a bucket of possibilities. That mechanism, and its exact privacy limits, belongs to chapter 15, “Cracking a Password”, which sets it out with the arithmetic.

Guidance is not law, and the old rules are still written into contracts#

SP 800-63 is a NIST Special Publication. It is binding on United States federal agencies and on the systems that serve them, and it is voluntary for everyone else. It is not a statute, it does not apply to a company in Pune or Manchester because it exists, and no regulator outside that chain will fine you for ignoring it.

What forces most organizations into the old rules is a different set of documents: payment-industry requirements, customer security questionnaires, insurance forms, audit checklists written in 2011 and copied ever since, and the default settings of the products they bought. Those change slowly, and many still carry the ninety-day rule and the four-class rule as flat requirements. The skill worth having is not to quote NIST at people. It is to know which line in your policy came from evidence and which came from a checklist, so that when you are asked to justify a change you can do it from the sources.

Accepting Unicode is where good intentions meet broken login screens#

The plain version says accept anything the user can type, including accented letters and other alphabets. That is the right instruction and it has a sharp edge.

The same visible character can be typed in more than one way. The letter e with an acute accent can arrive as one code point, or as a plain e followed by a separate combining accent. Both look identical on screen. If you store the hash of one form and the user’s next device sends the other form, the password will be rejected and neither you nor the user will have any idea why. That is why the specification tells you to normalize, which means converting to one agreed form before hashing.

The edge is this: if you ever change which normalization form you use, every existing stored password that contained a character affected by the change becomes unverifiable. The user types the same password and it fails. And the 2025 revision did change the recommended form. The 2017 edition told verifiers to use NFKC or NFKD, the compatibility forms; the 2025 edition tells them to use NFC, the canonical composition form. A system that follows the current advice by switching forms, without a migration plan, will lock out exactly the users whose passwords contain the characters it was trying to support.

The honest version: “accept Unicode” is a two-part instruction. Accept it, and pin the normalization form in writing next to the stored hash, so that a future change of policy can be applied to new passwords only. We will do this properly in the technical half.

The technical version#

The document that started it: SP 800-63, Appendix A#

The publication is NIST Special Publication 800-63, “Electronic Authentication Guideline”, Version 1.0, by William E. Burr, Donna F. Dodson and W. Timothy Polk of the National Institute of Standards and Technology. The NIST catalogue records its date of publication as 30 June 2004, and its withdrawal on 27 September 2004 in favour of the next version of the same number, version 1.0.1. Burr and the press consistently date the work to 2003, which is when it was drafted and circulated; if you need a single year for the document itself, 2004 is the published one, and it is worth saying both so that nobody thinks you have muddled them.

The part that changed the world is Appendix A, titled “Estimating Password Entropy and Strength”. It opens by leaning on Claude Shannon’s measurements of the predictability of English text, published in 1948 and 1951, and reasons as follows: since users pick passwords that resemble language, and since language is predictable in a way that gets stronger as the string goes on, we can approximate the guessing difficulty of a user-chosen password by assigning fewer and fewer bits per character as the password lengthens.

Here is the scheme, in the document’s own terms.

The composition bonus is described in the appendix as applying to “a composition rule that requires both upper case and non-alphabetic characters”, and the same bullet point warns that forcing those characters “reduces the total search space somewhat, so the benefit is probably modest and nearly independent of the length of the password”. The dictionary bonus applies to “an extensive dictionary check”, specified elsewhere in the appendix as a list of at least 50,000 commonly selected passwords, compared after converting the candidate to lower case, with detectable permutations of the username also refused. The appendix says the dictionary bonus “declines to zero at 20 characters”, on the reasoning that a memorable long password must be a phrase built of dictionary words anyway.

Two details from the same appendix are almost never quoted and both are useful. It states that “user chosen passwords of at least 15 characters are assumed to have at least 10-bits of min-entropy”, so the number 15, which the 2025 revision made a requirement, was already doing work in 2004. And it says plainly of its own output that the values “should not be taken as accurate estimates of absolute entropy” but only “a rough relative estimate”. The author told you it was rough. The industry printed the table on a poster.

The scoring sheet applied to a real password#

Table A.1 of the appendix is the part that got copied into a thousand internal standards. Here are six of its rows, all for a user-chosen password from the 94 printable characters of a United States keyboard, not counting the space.

For comparison, the same table gives a randomly chosen 8-character password from those 94 characters 52.7 bits, and a randomly chosen 20-character one 131.7 bits. The gap between 30 and 52.7 at the same length is the whole difference between a human choosing and a machine choosing.

Now score Anand’s password, “Sunita@01”, the way the college’s policy committee would have scored it in 2009. It is nine characters. The first character is worth 4. Characters two to eight are seven characters at 2 each, which is 14. The ninth character is worth 1.5. That is 19.5 before bonuses. The college enforces a capital and a symbol, so add the composition bonus of 6. The college also runs a dictionary check, and at nine characters the table’s own rows imply a dictionary bonus of about 5 or 6, since the gap between the “no checks” and “dictionary” columns is 6 bits at length 8 and 5 bits at length 10. The total lands at about 31 bits, bracketed by the table’s own values of 30 at eight characters and 32 at ten.

Thirty-one bits. In 2009 that number looked respectable, and the committee wrote “our password policy provides approximately 31 bits of entropy” in a document that is probably still on a shared drive.

Now count what an attacker actually has to do. He does not search 2 to the power 31. He searches the shape the policy created. A list of 100,000 common Indian first names, capitalized, times the eight symbols the college permits, times the 100 possible two-digit endings, is 80 million candidates, which is about 2 to the power 26. Against a fast stored hash that is a fraction of a second of one graphics card; chapter 15 gives the measured rates. And that is the attacker who knows nothing. The attacker who has seen one old password of Anand’s does not need 80 million guesses; he needs to try incrementing the counter, which is one guess.

Score the passphrase under the same 2004 scheme and something quietly damning happens. “sunita cooks at seven” is 21 characters: 4 for the first, 14 for characters two to eight, 18 for the twelve characters from nine to twenty, and 1 for the twenty-first. That is 37 bits, with no composition bonus and no dictionary bonus, against 31 for the password the policy demanded. The scoring sheet that was used to justify composition rules rated the unfashionable, rule-breaking passphrase higher than the compliant password, and would have done so at any point in the last twenty-two years, had anyone applied it to a string the policy did not allow. The appendix could not quite describe our phrase, because its alphabet of 94 characters excludes the space, which is itself a small monument to how the era thought about passwords.

What Burr said in 2017, and what the record shows#

The Wall Street Journal published Robert McMillan’s interview with Bill Burr on 7 August 2017, under a headline that wrote “never mind” as a password: “The Man Who Wrote Those Password Rules Has a New Tip: N3v$r M1^d”. Burr, then 72 and retired from NIST, is quoted saying “Much of what I did I now regret”, and describing the guidance as having been “too complicated for a lot of folks to understand very well” and as “barking up the wrong tree”.

Three points of precision, because this interview is quoted more often than it is read. He was talking about the family of advice in Appendix A, the composition scoring and the encouragement of frequent change; he did not say passwords are useless and did not propose an alternative in the article. He was one of three named authors, and the appendix was published by an institution rather than by a private individual, so blaming or crediting one person is convenient and wrong. And the retraction that matters is not the interview at all: it is NIST SP 800-63B, published in June 2017, two months earlier, which changed the requirements. When you cite this history, cite the publication and mention the interview, not the other way round.

SP 800-63B of June 2017: the clauses, exactly#

In June 2017 NIST replaced the single 800-63 document with a suite of four: SP 800-63-3 as the overview, 800-63A on identity proofing, 800-63B on authentication, and 800-63C on federation. SP 800-63-2 was formally withdrawn on 22 June 2017. The rules for passwords, which the document calls memorized secrets, live in SP 800-63B section 5.1.1.2, “Memorized Secret Verifiers”. An errata update was issued on 2 March 2020, and that version stood as the current one until 2025.

The clauses, in the document’s own words and its own capitalization of requirement levels:

Verifiers SHALL require subscriber-chosen memorized secrets to be at least 8 characters in length. Verifiers SHOULD permit subscriber-chosen memorized secrets at least 64 characters in length. All printing ASCII characters as well as the space character SHOULD be acceptable in memorized secrets, and Unicode characters SHOULD be accepted as well. For the purposes of the length requirements, each Unicode code point SHALL be counted as a single character. Truncation of the secret SHALL NOT be performed. If Unicode characters are accepted, verifiers SHOULD apply the Normalization Process for Stabilized Strings using either NFKC or NFKD normalization.

When processing a request to establish or change a memorized secret, verifiers SHALL compare the prospective secret against a list containing values known to be commonly used, expected or compromised, and the document lists as examples passwords from previous breach corpuses, dictionary words, repetitive or sequential characters, and context-specific words such as the name of the service and the username. Verifiers SHOULD NOT impose other composition rules, for example requiring mixtures of different character types. Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily, for example periodically, but SHALL force a change if there is evidence of compromise. Verifiers SHALL NOT permit the subscriber to store a hint that is accessible to an unauthenticated claimant, and SHALL NOT prompt subscribers to use specific types of information, such as the name of their first pet, when choosing memorized secrets.

Appendix A of the same document, “Strength of Memorized Secrets”, is the reasoning, and it is worth reading once in full. Two sentences carry the argument. On composition: “analyses of breached password databases reveal that the benefit of such rules is not nearly as significant as initially thought, although the impact on usability and memorability is severe.” On the whole approach: “Length and complexity requirements beyond those recommended here significantly increase the difficulty of memorized secrets and increase user frustration. As a result, users often work around these restrictions in a way that is counterproductive.”

That last sentence is the entire chapter in twenty-nine words, published by the same body that had supplied the arithmetic for the rules it was abandoning.

SP 800-63 revision 4 of July 2025: what changed#

NIST published the fourth revision of the suite as final in July 2025; the catalogue entry for SP 800-63B-4, “Digital Identity Guidelines: Authentication and Authenticator Management”, records the release date as 31 July 2025, and states that it supersedes the March 2020 version of SP 800-63B. It went through a first public draft in December 2022 and a second in August 2024. As of August 2026 this is the current version. The password rules moved from section 5.1.1.2 to section 3.1.1.2, “Password Verifiers”, and the document now says “password” throughout instead of “memorized secret”.

The changes are not cosmetic. Here is the comparison that belongs in your policy document.

Read the first two rows carefully, because this is the single most misquoted point in the current guidance. Revision 4 says that verifiers and credential service providers “SHALL require passwords that are used as a single-factor authentication mechanism to be a minimum of 15 characters in length”, and that they “MAY allow passwords that are only used as part of multi-factor authentication processes to be shorter but SHALL require them to be a minimum of eight characters in length”. So fifteen is now the floor for a password standing on its own, and eight survives only when the password is one of two or more factors.

The maximum stays where it was: verifiers “SHOULD permit a maximum password length of at least 64 characters”. That is a requirement to accept, not a requirement to impose. A system that refuses a 40-character passphrase is failing this clause even though it has no rule that mentions 40.

Two prohibitions became SHALL NOT, the strongest form: “Verifiers and CSPs SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords” and “Verifiers and CSPs SHALL NOT require subscribers to change passwords periodically”. The second is immediately qualified: “However, verifiers SHALL force a change if there is evidence that the authenticator has been compromised.” Under the current guidance, a scheduled expiry is not a weak practice you may keep for tradition. It is a violation.

The hint and question bans are unchanged in substance and unchanged in strength: no hint accessible to an unauthenticated claimant, and no prompting the subscriber to use knowledge-based authentication or security questions when choosing a password.

Three additions are new and practical. Verifiers “SHALL request the password to be provided in full (not a subset of it)” and “SHALL verify the entire submitted password (e.g., not truncate it)”, which outlaws the banking habit of asking for the third, fifth and ninth characters. Verifiers “SHALL allow the use of password managers and autofill functionality” and “SHOULD permit claimants to use the ‘paste’ function”. And “the verifier SHOULD offer an option to display the password, rather than a series of dots or asterisks, while it is entered”, with the reasoning that a claimant in a private place should be able to check what they typed.

One small mercy is also new. Verifiers “MAY make limited allowances for mistyping (e.g., removing leading and trailing whitespace characters before verification, allowing the verification of passwords with differing cases for the leading character) if the password remains at least the required minimum length after such processing and the complexity of the resulting password is not significantly reduced”. That is permission to forgive a stray space or a capital produced by a phone keyboard, bounded so that it cannot be used to shave a password down.

Why periodic rotation makes passwords worse, with the evidence#

The case against scheduled expiry is not an opinion, and you should be able to produce it from memory in a meeting.

The empirical result is Yinqian Zhang, Fabian Monrose and Michael K. Reiter, “The Security of Modern Password Expiration: An Algorithmic Framework and Empirical Analysis”, published at the ACM Conference on Computer and Communications Security in 2010. They obtained 51,141 unsalted MD5 password hashes from 10,374 defunct accounts of the ONYEN single-sign-on system at the University of North Carolina at Chapel Hill, used between 2004 and 2009, with four to fifteen successive passwords for each account. The site’s policy required a change every three months. After cracking, they analysed 7,752 accounts whose password histories they could read, and asked a simple question: given one of a user’s old passwords, how hard is the next one?

Their answer is the number that ended the argument. Knowing an old password, an attacker searching offline broke roughly 41 per cent of the following passwords “in under 3 seconds” per account. In the online case, where guesses are limited, “an average of 17 per cent of accounts can be broken in under five online password guesses in expectation”. Five guesses is inside any lockout threshold ever written. The mechanism is exactly what you would predict from Anand: users apply small transformations, incrementing a digit, moving a symbol, changing a letter’s case, and the transformations are drawn from a short, learnable list. The authors’ own conclusion is blunt: “our evidence suggests it may be appropriate to do away with password expiration altogether”.

The theoretical result is Sonia Chiasson and Paul C. van Oorschot, “Quantifying the security advantage of password expiration policies”, published in the journal Designs, Codes and Cryptography in 2015. They model an attacker performing an exhaustive search while the defender changes the password on a schedule, and ask how much the schedule reduces the attacker’s success. Even under assumptions generous to the defender, the answer is small: the best a policy-driven change can do is take the attacker’s probability of success from certainty down to about 0.75, and in the more realistic case where the attacker can search the space faster than the change interval, to no lower than about 0.632. Their point is not that expiry does nothing, but that its ceiling is low even before you account for the users who respond by choosing weaker passwords in the first place.

The policy consequences followed in order. On 2 March 2016 Lorrie Cranor, then Chief Technologist at the United States Federal Trade Commission, published “Time to rethink mandatory password changes”, citing the Chapel Hill study and recommending that organizations weigh the costs and benefits rather than force everyone to keep changing. In 2017 SP 800-63B told verifiers they SHOULD NOT require arbitrary changes. In 2019 Microsoft removed password-expiration settings from its recommended Windows security baseline, in the baseline for Windows 10 version 1903, published in final form on 23 May 2019, with reasoning that has been quoted ever since: “Periodic password expiration is an ancient and obsolete mitigation of very low value”, noting that the baseline had been saying 60 days and had previously said 90. In 2025 SP 800-63B revision 4 turned the SHOULD NOT into a SHALL NOT.

The United Kingdom’s National Cyber Security Centre reached the same place independently and says it in plainer English than anyone. Its password policy guidance states that “forcing password expiry carries no real benefits because the user is likely to choose new passwords that are only minor variations of the old” and that “stolen passwords are generally exploited immediately”. It requires a change only when compromise is known or suspected. Its predecessor body CESG had published the first version of this advice, “Password Guidance: Simplifying Your Approach”, jointly with CPNI in September 2015, before NIST moved.

Length over composition: where 8, 15 and 64 come from#

The modern position is that length is the lever and composition is not, and the reason is not aesthetic. Composition rules do not add unpredictability; they relocate it. If you demand a capital, most people capitalize the first letter. If you demand a digit, most people append one or two at the end, very often a year. If you demand a symbol, most people use one of three symbols in one of two positions. An attacker’s mask, which is a template describing the shape of a password, becomes more accurate the more classes you require, because your rule has told him which shapes to try.

The measurement most worth knowing is Saranga Komanduri, Richard Shay, Patrick Gage Kelley, Michelle Mazurek, Lujo Bauer, Nicolas Christin, Lorrie Faith Cranor and Serge Egelman, “Of Passwords and People: Measuring the Effect of Password-Composition Policies”, at CHI 2011, with 5,000 participants. They compared a policy requiring 16 characters and nothing else with a policy requiring 8 characters, all four character classes and a dictionary check. The 16-character policy produced passwords with 44.67 bits of estimated entropy against 34.30 bits for the comprehensive one, and it also did better on usability: easier to create, reported as easier to remember, and less likely to be written down.

The 2020 study by Joshua Tan, Lujo Bauer, Nicolas Christin and Lorrie Faith Cranor at ACM CCS, “Practical Recommendations for Stronger, More Usable Passwords Combining Minimum-strength, Minimum-length, and Blocklist Requirements”, sharpened the finding with modern guessing attacks. Their conclusion on character classes is worth quoting because it goes further than “not much help”: “against expert attackers, character-class requirements, traditionally associated with producing stronger passwords, in practice may provide very little improvement and may even reduce effective security”. Their recommended policy for accounts worth protecting is a twelve-character minimum combined with a minimum-strength requirement set at ten to the power ten guesses, measured by a neural network trained on password data. Where an organization prefers a blocklist, they recommend an eight-character minimum with either fuzzy matching against a list of about a hundred thousand leaked passwords or full-string matching against a very large leaked list, and they add the rule that a policy using a blocklist should not also impose character-class requirements.

So where do the three numbers in the current guidance come from?

Eight is the historical floor, inherited from the 2017 edition, which chose it as the point below which brute force and dictionary attacks succeed quickly. It survives in revision 4 only for passwords used alongside another factor.

Fifteen is the new floor for a password used alone. Fifteen characters is long enough that no mask over the printable characters is searchable, and it is short enough to be a four-word phrase. It is not a new invention: the 2004 appendix already treated fifteen characters as the point where a user-chosen password could be assumed to carry at least ten bits of min-entropy.

Sixty-four is not a limit you impose, it is a limit you must tolerate. Its purpose is to make room for password managers and generated passphrases. The reasoning is given in the 2017 appendix: “Since the size of a hashed password is independent of its length, there is no reason not to permit the use of lengthy passwords (or pass phrases) if the user wishes”, with the caveat that some ceiling is reasonable so that nobody submits a megabyte to your hash function.

One implementation trap connects to storage and is worth one line here. The bcrypt function ignores input beyond 72 bytes, so a system that accepts 64 characters of Unicode and stores them with plain bcrypt may be silently ignoring the tail of a long passphrase, because one character is not one byte. What to do about that belongs to chapter 14, “Storing a Password”; the rule in this chapter is only that your length check counts code points and your storage layer must be told the truth about what it is being handed.

Every printable character, Unicode, and normalization before hashing#

The character-set requirements are short. Accept all printing ASCII characters and the space. Accept Unicode. Count each Unicode code point as one character when you measure length. Never truncate. The instruction to accept the space is the one that makes a passphrase possible, and a great many input fields still strip it; the instruction to count code points rather than bytes is what stops “naive” with a diaeresis being six characters on one server and five on another.

Normalization is the part that gets skipped and then causes an outage. The same visible text can have more than one representation in Unicode, and the two representations are different byte strings, so they hash differently.

"cafe" with an acute accent, decomposed (NFD):
  63 61 66 65 CC 81     6 bytes, 5 code points
the same word, composed (NFC):
  63 61 66 C3 A9        5 bytes, 4 code points
Identical on screen. Different input to the hash.

Which form arrives at your server depends on the operating system and the input method, not on the user. A macOS filesystem hands you decomposed text; most Windows and Linux input produces composed text; a phone keyboard may produce either. So a password set on one device and typed on another will fail to verify unless you convert both to a single agreed form first.

The 2017 edition told verifiers to apply “the Normalization Process for Stabilized Strings using either the NFKC or NFKD normalization” defined in Unicode Standard Annex 15. The 2025 edition changed this: “If Unicode characters are accepted in passwords, the verifier SHOULD apply the normalization process for stabilized strings using the Normalization Form Canonical Composition (NFC) normalization defined in Sec. 12.1 of Unicode Normalization Forms.” It also adds a sensible warning to tell users that “some endpoints may represent some characters differently, which would affect their ability to authenticate successfully.”

The difference between the two families is not decorative. The canonical forms, NFC and NFD, treat only characters that are genuinely the same character. The compatibility forms, NFKC and NFKD, additionally collapse characters that merely look related: the single-character ligature for “fi” becomes two letters, a circled digit becomes a plain digit, full-width Latin letters become ordinary ones. Compatibility normalization therefore destroys distinctions a user may have deliberately made. NIST does not publish a rationale beside the changed requirement, so treat this as the obvious reading rather than an official one: canonical normalization fixes what must be fixed, two encodings of one character, without discarding differences that are real.

The operational rule that follows is the one nobody writes down until after the incident. Record the normalization form beside the stored hash, as a field, so that a future change of policy applies to new and changed passwords only and never invalidates the existing ones.

{
  "user": "anand.kulkarni",
  "algo": "argon2id",
  "params": "m=65536,t=3,p=1",
  "norm": "NFC",
  "policy_min_len": 15,
  "set_at": "2026-08-17T09:14:22Z",
  "hash": "RdescudvJCsgt3ub+b+dWRWJ"
}

The hash value there is shortened so that it fits the page. The point of the record is the “norm” field: without it, a change of normalization form is an outage with no diagnosis, because the only symptom is a population of users who insist their password is correct.

Here is the whole path a submitted password should take before it reaches the hash function.

user types:  s u n i t a _ c o o k s _ a t _ s e v e n
     |
     v
 [1] take the bytes as UTF-8; do not trim the middle,
     do not truncate, do not reject on shape
     |
     v
 [2] decode to code points and count them: 21
     |
     v
 [3] normalize to NFC; record "NFC" with the record
     |
     v
 [4] length: 21 is at least 15, and under 64 -> pass
     |
     v
 [5] blocklist: compare the whole string, case-folded,
     against breach list, dictionary, site terms
     |
     v
 [6] hand the normalized string to the password hash
     (chapter 14 chooses the function and the cost)

Blocklists: what to load, how to match, how big#

The blocklist is the rule that replaced composition, and it is the one that actually works, because it attacks the real problem: people choose passwords other people have already chosen.

What to load. Revision 4 requires the comparison and names three sources as examples: passwords obtained from previous breach corpuses, dictionary words, and context-specific words such as the name of the service, the username, and derivatives of them. The 2017 edition added repetitive or sequential characters, such as “aaaaaa” and “1234abcd”, which remains sensible practice. The context-specific category is the one most often forgotten and the most valuable per entry: for Anand’s college, the college’s name, its abbreviation, the town, the mascot, the year of founding, the names of its buildings and its systems.

How to match. Revision 4 is explicit that “the entire password SHALL be subject to comparison, not substrings or words that might be contained therein”. That instruction is aimed at over-eager implementations that reject “mypasswordisgood” because it contains “password”; the whole string is what you compare against a breach list. Context-specific terms are a separate matter, and the standard practice there is substring matching, because a password containing the site’s own name is a bad password no matter what surrounds it.

The best-documented production implementation is Microsoft Entra Password Protection, and it is worth studying because it shows what “compare properly” means in code. It keeps a global banned list built from Microsoft’s own telemetry, plus a custom list an organization supplies, capped at 1,000 terms. When a password is submitted it is normalized to lower case with common substitutions undone, so that a zero becomes an “o”, a one becomes an “l”, a dollar sign becomes an “s” and an at-sign becomes an “a”. It then does fuzzy matching at an edit distance of one against the banned lists, and substring matching for the user’s first name, last name and the tenant name, for terms of at least four characters. Then it scores: each banned term found in the password counts one point, each remaining character counts one point, and the password must reach at least five points to be accepted.

Custom banned list: nagpur, vidyapeeth
Candidate "Nagpur1"
  normalize        -> nagpur1
  banned term hit  -> nagpur          = 1 point
  characters left  -> "1"             = 1 point
  total 2, needs 5                    -> rejected
Candidate "Nagpur@2024"
  normalize        -> nagpura2024  (@ becomes a)
  banned term hit  -> nagpur          = 1 point
  characters left  -> "a2024"         = 5 points
  total 6, needs 5                    -> accepted

That second result is worth sitting with, because it is honest about what a blocklist is. A score-based check is a heuristic, not a strength measurement, and “Nagpur@2024” passes it while remaining a poor password. Blocklists remove the catastrophic choices. They do not certify the survivors.

How big. The current guidance says the blocklist “SHOULD be of sufficient size to prevent subscribers from choosing passwords that attackers are likely to guess before reaching the attempt limit”, and then, unusually for a standards document, warns against excess: “Excessively large blocklists are of little incremental security benefit because the blocklist is used to defend against online attacks, which are already limited by the throttling requirements”. The throttling requirement is in section 3.2.2 of the same document, which caps consecutive failed attempts on one account at 100. If an attacker gets at most 100 guesses, a list covering the most popular hundred thousand passwords already covers everything he could reach. The research agrees from the other direction: the 2020 CCS study used a list of 96,480 passwords, being those appearing four or more times in a leaked corpus of ten million, and found it competitive with a 555-million-entry breach list when the matching was done well.

There is also a storage note from that paper that saves arguments about cost: a comprehensive set of leaked passwords is about 30 gigabytes uncompressed, while a Bloom filter, a compact structure that answers “is this in the set” with a small chance of a false yes, holds the same set in about 1.1 gigabytes at a false-positive rate of 0.1 per cent. A false positive here costs a user one rejected password, which is a cheap failure.

Finally, revision 4 makes the follow-up mandatory: “If the chosen password is found on the blocklist, the CSP SHALL require the subscriber to select a different secret and SHALL provide the reason for rejection”, and “Verifiers SHALL offer guidance to the subscriber to help the subscriber choose a strong password”. Rejecting without explaining produces the worst outcome, which is a user trying “Nagpur@2025” next.

Hints and knowledge-based answers: why both are banned#

These two bans are often read as fussiness. They are not; each closes a documented, catastrophic hole.

The hint is banned because it is a plaintext clue stored beside the secret and shown to anyone who asks for it. The Adobe breach of October 2013 is the case that settled the matter. A file of 152,445,165 records became public. The passwords in it were not hashed but encrypted with Triple DES in a mode that maps the same password to the same ciphertext every time, so identical passwords were visibly identical in the file. Beside them sat the users’ password hints, in plain text. The combination is what made the file so damaging: you did not have to break the encryption at all. You grouped the records by ciphertext, read the hints attached to a group, and deduced the password that all of them shared. The web comic xkcd captured it in strip 1286, “Encryptic”, by presenting the leak as a crossword puzzle, which is exactly what it was. Adobe maintained that only about 38 million of the records belonged to active users.

The current rule is therefore that a hint may not be stored where an unauthenticated party can retrieve it. That covers the visible cases, and it also covers the modern equivalent, which is a password reset page that displays a hint after you type only a username.

Knowledge-based authentication, the “security question”, is banned for a different reason: the answers are neither secret nor memorable. The evidence is Joseph Bonneau, Elie Bursztein, Ilan Caron, Rob Jackson and Mike Williamson, “Secrets, Lies, and Account Recovery: Lessons from the Use of Personal Knowledge Questions at Google”, presented at the World Wide Web Conference in 2015, drawing on hundreds of millions of real questions and answers from Google accounts.

Their guessing results dismantle the idea that these questions carry a secret. An attacker with a single guess would succeed on 19.7 per cent of English-speaking United States users for the question “what is your favourite food”, because the answers cluster on a handful of foods. With ten guesses, an attacker would reach 39 per cent of Korean-speaking users’ answers to “what is your city of birth”. The distributions are not flat, they are dominated by a few answers, and the attacker knows the distributions.

Their memorability results dismantle the other half of the idea. Recall of one’s own answers decayed sharply: a year after enrolment the recall rate had fallen to 47 per cent for “what is your favourite food” and to 50.1 per cent for “what was your first phone number”. And the users who tried to fix the guessability problem made it worse: of those who admitted giving false answers, 37 per cent said they did so to make the answers harder to guess, and the paper observes that people “harden” answers in predictable ways, so the behaviour “achieves exactly the opposite effect”.

A mechanism a stranger passes one time in five, and the owner fails about half the time a year later, is not an authentication factor. It is a second, weaker password with a public clue attached. The current rule forbids prompting for such questions when choosing a password. Their remaining role in account recovery, and why even that role is now discouraged, is the subject of chapter 24, “Recovery”.

Rate limiting is the reason the rest of this can be gentle#

One clause underwrites the whole modern approach and it belongs here in a sentence, because without it the argument for gentleness collapses. Section 3.2.2 of SP 800-63B revision 4 requires verifiers to implement a rate-limiting mechanism, and caps consecutive failed authentication attempts on a single subscriber account at no more than 100 before that authenticator is disabled.

That number is what makes a hundred-thousand-entry blocklist sufficient, and it is what makes it safe to stop nagging users about symbols. The attacker at your login form gets a hundred tries, not a hundred million. The attacker who has stolen your database gets as many as he can pay for, which is why storage matters and why chapter 15 is about the arithmetic of that purchase. The rules in this chapter defend the first attacker. They are not, and are not meant to be, a defence against the second.

The two policies, side by side#

Here is the deliverable. On the left, the policy an enormous number of sites still enforce in August 2026. On the right, what the current guidance requires. Every line on the right is traceable to a clause quoted earlier in this chapter.

The left column is not a caricature. In 2022 Kevin Lee, Sten Sjöberg and Arvind Narayanan of Princeton University measured the password-creation policies of 120 of the most popular English-language websites and published the results at the Symposium on Usable Privacy and Security. Their findings, with the caveat that they were gathered three years before revision 4 was published:

Among the 54 sites that imposed character-class requirements, 98.1 per cent required a digit, 68.5 per cent required a symbol, 57.4 per cent required a lower-case letter and 55.6 per cent required an upper-case letter. The paper’s own definition of following best practice was modest: accept at most five of the forty most common leaked and easiest-guessed passwords, require at least eight characters, and impose no character-class requirements. Seven sites in eight failed it.

Writing it in code#

The wrong policy fits on one line, which is a large part of why it spread. Here it is, in the form it appears in a thousand codebases.

PCP = (r"^(?=.*[a-z])(?=.*[A-Z])(?=.*\d)"
       r"(?=.*[@#$%^&+=!])"
       r"[A-Za-z\d@#$%^&+=!]{8,12}$")

That expression accepts “Sunita@01”, “P@ssw0rd1” and “Nagpur#24”, and rejects “sunita cooks at seven” four times over: it contains a space, it has no digit, it has no capital, and it is far too long. Every property the expression tests is a property an attacker also knows. It certifies the shape and says nothing about the choice.

The correct check is longer, because it does real work. It counts code points, normalizes once, compares whole strings against a breach list, matches context terms as substrings, and gives a reason.

import unicodedata

MIN_LEN = 15        # single factor, SP 800-63B-4 3.1.1.2
MIN_LEN_MFA = 8     # only when a second factor is used
MAX_ACCEPT = 64     # must accept at least this many

def prepare(raw, floor):
    # Allowed mistyping relief: ends only, never the
    # middle, and only if it stays long enough.
    trimmed = raw.strip(" ")
    if len(trimmed) < floor:
        trimmed = raw
    # One agreed Unicode form. Store the name of the
    # form beside the hash; see the record above.
    return unicodedata.normalize("NFC", trimmed)

def check(raw, username, email, site_terms,
          breached, mfa_enrolled):
    floor = MIN_LEN_MFA if mfa_enrolled else MIN_LEN
    pw = prepare(raw, floor)
    n = len(pw)                  # code points, not bytes
    if n < floor:
        return f"use at least {floor} characters"
    if n > MAX_ACCEPT:
        return f"maximum is {MAX_ACCEPT} characters"

    folded = pw.casefold()
    if folded in breached:       # whole string, not parts
        return ("that password has appeared in a public "
                "breach; please choose another")

    local = email.split("@")[0]
    for term in set(site_terms) | {username, local}:
        if len(term) >= 4 and term.casefold() in folded:
            return ("please do not use our name or your "
                    "own name in a password")
    return "ok"

Four properties of that function are worth naming, because each corresponds to a clause.

It has no composition test at all, which is required, not merely permitted. It measures len(pw) after decoding, so a code point is one character however many bytes it occupies. It compares the whole folded string against the breach set, and only uses substring matching for context terms, which is the distinction revision 4 draws. And it returns a reason in words rather than a boolean, because the standard requires you to say why you rejected the password and to help the subscriber pick a better one.

What the function does not do is expire anything. There is no field for the date the password must be changed, because under the current guidance that field should not exist. What should exist is a path that forces a change when you learn of a compromise, driven by a breach feed rather than a calendar.

The worked example, finished#

Anand’s college rewrote its policy in 2026. The old rule, eight to twelve characters with three character classes and a change every ninety days, produced “Sunita@05”: about 31 bits by the discredited 2004 scoring sheet, about 80 million guesses to an attacker who knows the shape, and under ten guesses to an attacker who has seen any previous password in the series.

The new rule is one screen: at least 15 characters, up to 64, anything you can type including spaces, checked against a breach list and against the college’s own words, never expiring unless we learn it has leaked. Anand sets “sunita cooks at seven”. Twenty-one code points. Normalized to NFC and recorded as such. Not in the breach list. Contains none of the college’s terms. Accepted, and never asked for again.

One honest caveat before we leave him. A memorable sentence is not four random words. If Anand had chosen a line of film dialogue, a cricket commentary catchphrase or a verse everyone knows, it would already be in a wordlist, and its length would not save it. The strength of his choice comes from being a specific, dull fact about his own household, which no corpus contains. That is the advice to give users in words, and it is the advice the NCSC packages as “three random words”: pick words that go together only in your life, not in everyone’s.

16.98 Common wrong ideas#

Wrong: NIST invented password complexity rules in 2003. Right: Minimum lengths and character-class advice date from at least Morris and Thompson’s 1979 Communications of the ACM paper and the United States Department of Defense guideline CSC-STD-002-85 of April 1985; what NIST SP 800-63 Appendix A added in 2004 was a number, a six-bit bonus for a composition rule, and a number from a standards body is what turns a suggestion into a requirement.

Wrong: Bill Burr apologized, so the old rules are officially cancelled. Right: The interview of 7 August 2017 is colour; the binding change is NIST SP 800-63B of June 2017, which said verifiers SHOULD NOT impose composition rules or periodic change, and revision 4 of 31 July 2025, which upgraded both to SHALL NOT, so cite the publications and mention the interview.

Wrong: NIST says the minimum password length is eight characters. Right: Since revision 4 of July 2025 a password used as a single-factor authentication mechanism SHALL be at least 15 characters, and eight remains the minimum only for a password used as one factor inside a multi-factor arrangement.

Wrong: Sixty-four characters is the maximum NIST permits. Right: Sixty-four is a floor on your tolerance, not a ceiling on the user, since verifiers SHOULD permit a maximum length of at least 64 characters so that generated passphrases and password managers work; refusing a 40-character passphrase already breaks the clause.

Wrong: Making everyone change their password every ninety days is basic hygiene. Right: Zhang, Monrose and Reiter showed at CCS 2010 that knowing one old password broke about 41 per cent of the next ones offline in under three seconds and 17 per cent within five online guesses, Chiasson and van Oorschot showed in 2015 that the theoretical ceiling on the benefit is small, and revision 4 now forbids scheduled change outright.

Wrong: Forced password changes are now banned in every situation. Right: A change SHALL be forced when there is evidence the password has been compromised, rotation remains a crude but real control for shared and unattended credentials, and PCI DSS version 4.0.1 requirement 8.3.9 still demands a ninety-day change for password-only user access unless the organization performs dynamic analysis of account posture instead.

Wrong: The bigger the blocklist, the better the protection. Right: The blocklist defends against online guessing, which section 3.2.2 already caps at 100 consecutive failures, so a list of roughly a hundred thousand common and breached passwords covers everything an attacker can reach, and revision 4 warns in as many words that excessively large blocklists give little incremental benefit.

Wrong: A blocklist should reject any password containing a banned word. Right: Revision 4 requires the entire password to be compared, not substrings or words contained within it, so breach-list matching is whole-string; substring matching is reserved for context-specific terms such as the service name and the username, where a hit really does mean a bad password.

Wrong: Allowing spaces and Unicode invites trouble, so it is safer to restrict the character set. Right: All printing ASCII characters, the space, and Unicode SHOULD be accepted, each code point counts as one character for length, truncation is forbidden, and the only real hazard is normalization, which you handle by converting to NFC before hashing and recording the form you used beside the stored hash.

Wrong: Security questions add a second factor. Right: Bonneau and colleagues found at WWW 2015 that one guess recovers 19.7 per cent of English-speaking United States users’ answers to “favourite food” while barely half of those users could still recall their own answer a year later, so a security question is a weaker password with a public clue, and revision 4 forbids prompting for one when a password is chosen.

16.99 Chapter summary in 20 lines#

1. The composition rules almost every login form still enforces trace their authority to Appendix A of NIST Special Publication 800-63 version 1.0, published on 30 June 2004 and drafted in 2003 by William Burr, Donna Dodson and Timothy Polk.
2. That appendix was an estimating aid, scoring the first character of a password at 4 bits, characters two to eight at 2 bits each, nine to twenty at 1.5 bits and the rest at 1 bit.
3. It granted a bonus of 6 bits for a composition rule requiring both upper case and non-alphabetic characters, and up to 6 bits for a dictionary check against at least 50,000 entries, and those two bonuses are what the world copied.
4. Its own text called the composition benefit “probably modest” and said its numbers “should not be taken as accurate estimates of absolute entropy”, warnings that did not survive the journey into corporate policy.
5. Scheduled expiry did not come from that appendix either, which used lifetimes of two and ten years in its examples; the ninety-day habit came through audit checklists, while the 1985 Department of Defense guideline had set a maximum of one year.
6. Composition rules do not make a password unpredictable, they announce its shape, which is why “Sunita@01” collapses to about 80 million candidates once an attacker assumes name, symbol and two digits.
7. Forced rotation trains users to edit rather than replace, so Zhang, Monrose and Reiter recovered about 41 per cent of successor passwords offline in under three seconds and 17 per cent within five online guesses at CCS 2010.
8. Chiasson and van Oorschot showed in Designs, Codes and Cryptography in 2015 that even a generous model caps the benefit of expiry at reducing attacker success from certainty to about 0.75, and to about 0.632 in realistic conditions.
9. Lorrie Cranor advised the United States Federal Trade Commission’s readers to rethink mandatory changes on 2 March 2016, and Microsoft removed expiration from its Windows security baseline in May 2019, calling it “an ancient and obsolete mitigation of very low value”.
10. NIST SP 800-63B of June 2017 reversed the old rules, telling verifiers they SHOULD NOT impose composition rules and SHOULD NOT require arbitrary periodic change, and Bill Burr told the Wall Street Journal on 7 August 2017 “Much of what I did I now regret”.
11. Revision 4 of SP 800-63B, published on 31 July 2025 and current as of August 2026, upgraded both prohibitions to SHALL NOT and moved the password rules to section 3.1.1.2.
12. Revision 4 requires a minimum of 15 characters for a password used as a single factor, permits eight only when the password is part of a multi-factor process, and asks verifiers to accept a maximum of at least 64 characters.
13. Verifiers must accept all printing ASCII characters and the space, should accept Unicode, must count each Unicode code point as one character, and must verify the whole password without truncating it.
14. Unicode acceptance requires normalization, and the recommended form changed from NFKC or NFKD in 2017 to NFC in 2025, so the form used must be recorded beside each stored hash or a future change becomes an unexplained outage.
15. A blocklist of known common, expected and compromised passwords is mandatory, must be compared against the entire password rather than substrings, and must be paired with a stated reason for rejection and guidance towards a better choice.
16. Blocklists have a useful size limit, because section 3.2.2 caps consecutive failed attempts at 100, so about a hundred thousand entries covers what an online attacker can reach and larger lists add little.
17. Password hints are forbidden where an unauthenticated party can read them, a rule written in the shadow of the Adobe breach of October 2013, in which 152,445,165 records carried plaintext hints beside deterministically encrypted passwords.
18. Knowledge-based questions are forbidden at password selection because one guess recovers 19.7 per cent of some answer distributions while only about half of users can still recall their own answer a year later.
19. Measured against these rules, most of the web still fails: of 120 top websites studied at SOUPS 2022, only 13 per cent followed all relevant best practices, 71 accepted every one of forty common passwords tested, and 45 per cent still demanded specific character classes.
20. The correct policy is shorter than the wrong one: make it long, accept anything typable, check it against a breach list, explain rejections, never expire it on a calendar, always expire it on evidence, and delete the hint box and the security questions.

Chapter sources: NIST Special Publication 800-63, “Electronic Authentication Guideline”, Version 1.0, William E. Burr, Donna F. Dodson and W. Timothy Polk, published 30 June 2004 and withdrawn 27 September 2004, Appendix A “Estimating Password Entropy and Strength” and Table A.1; NIST Special Publication 800-63B, “Digital Identity Guidelines: Authentication and Lifecycle Management”, June 2017 with errata of 2 March 2020, section 5.1.1.2 and Appendix A; NIST Special Publication 800-63B revision 4, “Digital Identity Guidelines: Authentication and Authenticator Management”, published 31 July 2025, sections 3.1.1.1, 3.1.1.2 and 3.2.2, following public drafts of December 2022 and August 2024; the withdrawal of SP 800-63-2 on 22 June 2017; Robert McMillan, “The Man Who Wrote Those Password Rules Has a New Tip: N3v$r M1^d”, The Wall Street Journal, 7 August 2017; Robert Morris and Ken Thompson, “Password Security: A Case History”, Communications of the ACM, volume 22, number 11, November 1979, pages 594 to 597; United States Department of Defense, CSC-STD-002-85, “Password Management Guideline”, 12 April 1985, sections 4.2.2.1 and 4.4.1 and Appendix C; Yinqian Zhang, Fabian Monrose and Michael K. Reiter, “The Security of Modern Password Expiration: An Algorithmic Framework and Empirical Analysis”, ACM Conference on Computer and Communications Security, 2010; Sonia Chiasson and Paul C. van Oorschot, “Quantifying the security advantage of password expiration policies”, Designs, Codes and Cryptography, 2015; Lorrie Cranor, “Time to rethink mandatory password changes”, United States Federal Trade Commission, 2 March 2016; Saranga Komanduri and colleagues, “Of Passwords and People: Measuring the Effect of Password-Composition Policies”, CHI 2011; Joshua Tan, Lujo Bauer, Nicolas Christin and Lorrie Faith Cranor, “Practical Recommendations for Stronger, More Usable Passwords Combining Minimum-strength, Minimum-length, and Blocklist Requirements”, ACM CCS 2020; Kevin Lee, Sten Sjoberg and Arvind Narayanan, “Password policies of most top websites fail to follow best practices”, Symposium on Usable Privacy and Security, 2022; Joseph Bonneau, Elie Bursztein, Ilan Caron, Rob Jackson and Mike Williamson, “Secrets, Lies, and Account Recovery: Lessons from the Use of Personal Knowledge Questions at Google”, World Wide Web Conference, 2015; UK National Cyber Security Centre, “Password policy: updating your approach”, retrieved August 2026, and CESG and CPNI, “Password Guidance: Simplifying Your Approach”, September 2015; Microsoft, “Security baseline for Windows 10 v1903 and Windows Server v1903”, final release published 23 May 2019; Microsoft Entra Password Protection documentation, global and custom banned password lists, retrieved August 2026; PCI DSS version 4.0.1, June 2024, requirements 8.3.6 and 8.3.9, with the 12-character minimum effective 31 March 2025; Unicode Standard Annex 15, “Unicode Normalization Forms”, section 12.1 on stabilized strings; Paul Ducklin, “Anatomy of a password disaster”, Sophos Naked Security, 4 November 2013, and Randall Munroe, xkcd 1286, “Encryptic”, November 2013, on the October 2013 Adobe breach of 152,445,165 records.