Compliance ate the password rule

In 2003 a mid-level manager at NIST named Bill Burr wrote eight pages that changed the password of nearly every office worker on earth. Mix upper and lower case. Add a digit. Add a special character. Start again every ninety days.

The research he needed had not been done. He worked from a paper written in the 1980s and reasoned forward from it.

Fourteen years later he told the Wall Street Journal: “Much of what I did I now regret.” He had been, he said, barking up the wrong tree.

That same year NIST published SP 800-63B and dropped both rules. No required mix of character types. No forced expiry.

By then the evidence was not ambiguous, and it pointed the other way. Forced rotation makes passwords weaker, because people are not random number generators. They iterate on a schedule. Password1! becomes Password2! in April and Password3! in July, and an attacker holding one old hash can walk the sequence forward in a handful of guesses. Complexity rules fail from the other end: told to add a symbol, people reach for the same small set of substitutions everyone reaches for, and every cracking dictionary has encoded them for years.

The story everyone tells

The story usually told about this is a story about an expert who got it wrong.

That is the least interesting thing in it.

He got it wrong the way careful people get things wrong. A deadline, thin evidence, a defensible reading of the only paper on the shelf. Put anyone competent in that chair in 2003 and something close to Appendix A comes out. Reasonable errors are ordinary. Most of them die within a year or two, as soon as somebody measures.

This one lived fourteen.

What the auditor can actually see

It survived because it stopped being a recommendation.

It became a clause in a compliance framework, then a row on an audit checklist, and an auditor holding a checklist does not ask whether ninety days makes anyone safer. An auditor cannot see whether you are secure. There is no instrument for that, no reading to take. What an auditor can see is whether password expiry is set to ninety days, because that is a field on a configuration screen with a number in it.

So that is the question that gets asked. And the answer to that question is the thing organisations arrange to produce.

I have written the ninety-day line into policy documents myself, for clients who needed to pass, after I had read the guidance saying not to.

Two prices

Failing an audit costs money on a known date, in front of a named person, with a certificate or a contract attached to the outcome.

Being insecure costs money later. Probably. To someone else. If anyone ever traces it back.

The checkbox pulled those two prices apart. Once they were apart, the rule was no longer competing on whether it worked. It was competing on whether it was easy to verify, and it was extremely easy to verify.

Correctness had stopped being the thing under selection.

What this should change

The useful lesson is not “audits are theatre.” Audits catch real things, and an organisation with no external check on it drifts in worse ways.

The useful lesson is narrower and more uncomfortable. Every control you can cheaply verify is a control that will eventually be optimised for verification rather than for effect. That is not a failure of the auditor or of the framework. It is what happens when the cost of failing the check and the cost of the underlying harm are paid by different people at different times.

So the question worth asking about any control you own is not “does this work?” It is: if this stopped working tomorrow, who would find out, and what would it cost them?

If the honest answer is “nobody, and nothing,” you are not running a control. You are running a checkbox, and it will outlive its own evidence by about fourteen years.