The Password Memo Was Honest. The Checklist Wasn’t.

By John

The standard version of this story is that one man at a US standards agency invented the password rules everyone hates, and later apologised. It is repeated in every article on the subject, and the apology is real. The rest of it does not survive reading the document.

The memo is more careful than its reputation. It states its own weakness in plain language, warns that its numbers are a rough approximation, and predicts — accurately, in 2004 — exactly how users would defeat the rules it was describing. It also never contained the requirement most often attributed to it.

What went wrong happened after publication, in the gap between a technical document and the checklist made from it.

What the memo actually said

The document is NIST Special Publication 800-63, Electronic Authentication Guideline, version 1.0, published 30 June 2004 by William Burr, Donna Dodson and W. Timothy Polk. Press coverage almost always calls it a 2003 memo; the archived PDF on NIST’s own Computer Security Resource Center is dated 2004.

The famous part is Appendix A, which tries to estimate how much entropy a user-chosen password actually has. There was no dataset to work from, so Burr reached for Claude Shannon’s mid-century experiments on the predictability of English text — the ones where people were shown a string of letters and asked to guess the next character.

The appendix does not hide this. It says so directly:

“It is a big assumption that passwords are quite similar to other English text, and it would be better if we had a large body of actual user selected passwords, selected under different composition rules, to work from, but we have no such resource, and it is at least plausible to use Shannon’s work for a ‘ballpark’ estimate.”

And then, in case the reader missed it:

“Readers are cautioned against interpreting the following rules as anything more than a very rough rule of thumb method to be used for the purposes of E-authentication.”

The model that follows is deliberately crude: four bits of entropy for the first character, two bits each for the next seven, 1.5 bits through the twentieth, one bit after that. On top of this sits the number that became a global habit. A composition rule requiring both upper-case and non-alphabetic characters earns a bonus of six bits — with the appendix noting in the same sentence that because those characters tend to land at the start or the end, “the benefit is probably modest.” An extensive dictionary check earns up to six bits more, declining to zero at twenty characters.

Six bits. That is the entire estimated security value of the rule that has made hundreds of millions of people invent a capital letter and an exclamation mark, in a table its author labelled a rough relative estimate at best.

It predicted its own failure

The most striking passage is not a caveat. It is a forecast.

“…the assumption here is that users will choose passwords that are almost entirely lower case letters, unless forced to do otherwise, and that rules that force them to include capital letters or non-alphabetic characters will generally be satisfied in the simplest and most predictable manner, often by putting a capital letter at the start (as we do in ordinary English) and punctuation or special characters at the end, or by some simple substitution, such as $ for the letter ‘s.’”

Written in 2004. That is Password1!. That is Pa$$word. That is, with reasonable confidence, a meaningful share of the credentials protecting whatever you are reading this on.

The appendix goes further and names the second-order effect too:

“Moreover rules that force passwords to appear to be highly random will be counterproductive because they will make the passwords hard to remember. Users will then write the passwords down and keep them in a convenient (that is insecure) place, such as pasted on their monitor.”

The document that supposedly gave us composition rules described, in advance, both the trivial workaround and the sticky note. Those two paragraphs sit a page away from the table everyone copied. The table travelled. The paragraphs did not.

The rule that was never in it

Here is the part the standard story gets flatly wrong.

Almost every retelling says the memo told people to change their passwords every 90 days. We checked. Not a summary, not a secondary source — the full text of the published PDFs.

SP 800-63 version 1.0 (2004) contains no periodic password change requirement. Neither does SP 800-63-1 (2011). Neither does SP 800-63-2 (2013). The phrase “life of the password” appears repeatedly, but it is used as a budget for how many guessing attempts an attacker gets, not as a shelf life. The only maximum lifetime specified anywhere in those revisions applies to temporary secrets sent over an unprotected channel, which must be reset on first use and expire within seven days.

Mandatory rotation has a different and older lineage. It is in CSC-STD-002-85, the Department of Defense Password Management Guideline — the “Green Book” — published on 12 April 1985. Its recommendation:

“It is recommended that the maximum lifetime of a password be no greater than 1 year.”

One year. The reasoning is stated plainly: “The greater the length of time during which a password is used for authentication purposes, the more opportunities there are for exposing it,” with shorter lifetimes advised where specific threats justify them.

So where did 90 days come from? Not from the memo everyone blames. It hardened in the compliance layer — in the audit standards that turn guidance into pass/fail. PCI DSS has long required password changes every 90 days, now at requirement 8.3.9; DISA STIGs specify 60 days for some applications; NIST SP 800-53’s IA-5 control leaves the interval as an organisation-defined parameter, which in practice means whoever fills in the blank decides.

That is the actual mechanism. A cautious 1985 recommendation of one year, a 2004 entropy estimate hedged by its own authors, and somewhere in between, a number nobody can source becoming the thing your auditor checks.

Twenty-one years to “shall not”

In August 2017, NIST rewrote the guidance. SP 800-63B dropped mandatory expiry and the special-character requirement. Paul Grassi, who led the revision, said the mandatory special characters had done little for security and “actually had a negative impact on usability.”

Burr, by then retired, told The Wall Street Journal: “Much of what I did I now regret.”

He is being harder on himself than the record warrants. He wrote a hedged estimate and said it was hedged. What he could not control was what happened to it downstream.

The current revision, SP 800-63-4, was finalised in July 2025 after nearly four years, two public drafts and roughly 6,000 comments. The language is no longer advisory. From section 3.1.1.2 of SP 800-63B:

“Verifiers and CSPs SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords.”

“Verifiers and CSPs SHALL NOT require subscribers to change passwords periodically. However, verifiers SHALL force a change if there is evidence that the authenticator has been compromised.”

Alongside those: a minimum of 15 characters for a password used as a single factor, eight where it is part of multi-factor authentication; mandatory checking against blocklists of known-compromised and commonly used passwords; no stored hints accessible to an unauthenticated claimant; and no security questions — “SHALL NOT prompt subscribers to use knowledge-based authentication (e.g., ‘What was the name of your first pet?’).”

Twenty-one years from the entropy table to the prohibition. Eight of those came after the reversal was published in plain English in 2017 — and the rules are still in production systems today, still in policies, still generating password-reset tickets this week.

How a requirement actually hardens

The interesting question is not why Burr got it wrong. It is why being right, publicly, in 2017, changed so little.

The answer is that the rule was never really living in the guidance document. It was living in audit standards, vendor default configurations, procurement questionnaires and internal policies written by people who had copied it from somewhere else. Each of those updates on its own schedule, for its own reasons, and none of them is obliged to notice that the source moved. A recommendation in a standards publication can be reversed by its authors. A line in a checklist has no author left to argue with — which is precisely the difference between being compliant and being secure that keeps showing up in audit work.

That is worth sitting with, because the mechanism is entirely general. Requirements do not become permanent by being correct. They become permanent by being copied — into enough documents, by enough people, that no single correction can reach all of them.

Which invites an uncomfortable inventory. Go through your own security policies and pick out the rules with a number in them: rotation intervals, minimum lengths, retention windows, review frequencies. For each one, try to name where the number came from and what evidence supported it. The ones you can answer for are fine. The ones you cannot are not necessarily wrong — but they are being enforced for the same reason 90 days was, and that reason turned out to be nothing more than the fact that someone else wrote it down first.