In August 2017, the Wall Street Journal ran an interview with Bill Burr, the former NIST manager who authored the 2003 government guidelines behind "must contain uppercase, lowercase, a number, and a symbol" and "change your password every 90 days." His assessment of his own advice, fourteen years later: "Much of what I did I now regret." That single sentence is a useful place to start, because the interesting question isn't just what a strong policy requires — Password Policy Generator and Password Policy Validator already answer that against current NIST guidance — it's why the rules changed underneath an entire industry, and what that reversal teaches about evaluating a policy in the first place.
Where the old rules came from
Burr wrote NIST Special Publication 800-63 Appendix A in 2003, and it became the reference point many organizations built their own policies around for the next decade and a half — composition requirements and mandatory rotation both trace back to it, directly or through a chain of policies copying each other. The guidance wasn't arbitrary: it was built on theoretical entropy modeling, extrapolated from older academic and military research on password strength. What it wasn't built on — because the data didn't exist yet in a usable form — was actual observation of how real people respond to being told "you must include a symbol" or "you must change this again."
What changed: real breach data
By the 2010s, researchers had something 2003 didn't: large corpora of real, leaked password databases to actually measure human behavior against, instead of modeling it theoretically. Two findings did the most damage to the old rules:
- Composition rules produce predictable patterns, not real entropy. Told to include a symbol, people overwhelmingly append one at the end. Told to include a number, people overwhelmingly use a year or increment an existing digit. A password cracker that checks these transformations first — capitalize the first letter, append
!or1, substitute@fora— recovers a large share of "compliant" passwords far faster than the theoretical entropy count would suggest, because the theoretical count assumes every character was chosen independently and unpredictably. It wasn't. - Forced rotation produces predictable successors, not fresh passwords. A widely cited 2010 study (Zhang, Monrose, and Reiter, presented at ACM CCS) analyzed sequences of a university's expired passwords and built an algorithm that predicted a user's next password from their previous ones — because most people, told to change a password they can already remember, make the smallest edit that satisfies the requirement: increment a number, swap a season, adjust a suffix. Knowing an old password in the sequence meaningfully narrowed down the next one, for a real share of accounts.
NIST SP 800-63B, published in June 2017 — the same year as Burr's interview — formalized the reversal: no mandatory rotation without evidence of compromise, no mandatory composition rules, an emphasis on length, and a newly explicit requirement (breach-checking) that the 2003 guidance had no way to specify, because Have I Been Pwned's Pwned Passwords corpus and services like it didn't exist yet either.
What 800-63B actually requires, briefly
The full checklist — minimum/maximum length, rotation, breach-checking, MFA, paste, and the rest — is covered in depth (and checked live against a document or free-text policy you provide) by Password Policy Generator and Password Policy Validator, so this stays brief: an 8-character hard floor with 15+ recommended, at least 64 characters supported, no forced rotation or composition rules, mandatory breach-checking, and paste allowed so password managers keep working.
A policy is more than the document
A policy that scores perfectly against every item above can still fail in two ways that have nothing to do with which rules it lists:
- It never actually gets adopted. A security lead convinced that composition rules are obviously safer — the same intuition that made the 2003 guidance feel reasonable at the time — overrides the NIST-aligned draft with the old rules anyway. Getting a policy accepted internally often means explaining why the old advice was reversed, not just citing that it was — which is the whole reason this post exists alongside the tools that check documents mechanically.
- It exists on paper without existing in production. A written policy that requires breach-checking means nothing if no code path actually calls a breach-check service. This is a different question from "is the document correct," and Password Storage Checker is built for it specifically — it grades what a system actually does (hashing algorithm, MFA, rate limiting, breach-checking) rather than what a document says it should do.
Where compliance frameworks haven't caught up
Not every framework that governs a given system has updated to match 800-63B — some versions of PCI-DSS and plenty of internal audit checklists still expect periodic rotation. Where a specific compliance requirement is genuinely stricter or different, that requirement is what you legally have to satisfy in that context — NIST 800-63B describes current security best practice, not a legal override. In practice this is rarely an all-or-nothing conflict: a policy can satisfy an external rotation requirement while still adopting everything else 800-63B recommends (no composition rules, breach-checking, paste allowed, MFA), rather than treating "our auditor requires rotation" as a reason to skip the rest of the reversal too.
A short framework for judging any policy
Beyond checking a specific document against a specific checklist, four questions travel well to a policy you haven't seen yet:
- Does it make the secure choice the easy choice? Allowing paste, supporting long passphrases, not adding arbitrary friction — a rule that fights how people (and password managers) actually work gets worked around, not followed.
- Does it target real attacks? Breach-checking stops credential stuffing and reused-password attacks, which are how most real accounts actually get compromised. Composition rules target a theoretical brute-force attack that's rarely the one that happens.
- Is it enforced, or just written down? The gap Password Storage Checker exists to check.
- Does it plan for the account lifecycle, not just account creation? A compromise-response path (force a reset immediately) and a dormant-account path (expire old hashes after a long enough idle window) both matter more than getting the initial rule set exactly right — see Password Hash Migration Strategies for the mechanics of the latter.
FAQ
Is NIST SP 800-63B legally binding?
It's mandatory for U.S. federal information systems and widely adopted as best practice elsewhere, but it isn't law for a private company by itself — a specific contract, industry regulation, or compliance framework might impose its own requirements on top of or instead of it.
Did Bill Burr's regret change anything officially?
Not directly — SP 800-63B was already in development based on the underlying research described above, and Burr had retired from NIST by the time it published. The interview is notable less as a cause and more as a strikingly honest acknowledgment, from the person most associated with the old rules, that the evidence had moved past them.
Where do I start if I'm updating an existing policy?
Paste the current policy's text into Password Policy Validator to see exactly which parts already align and which don't, then use Password Policy Generator to draft the replacement. Neither one addresses migrating an already-hashed user base — see Password Hash Migration Strategies if that's the next question.
Try it yourself
Password Policy Generator and Password Policy Validator check a policy against NIST SP 800-63B from either direction — settings in, or free text in. Password Storage Checker grades what a system actually enforces, separately from what the document says. All three run entirely in your browser, and Password Security: A Comprehensive Guide is the map connecting policy to the other layers — creation, storage, and defense beyond the password itself.