Over-strict rules produce weaker real passwords
Aliases: composition policy backlash · NIST password guidance
What it is
Composition rules (must include upper case, a digit, a symbol, forbid certain classes of words) are meant to raise guessing cost. Over-strict means the constraints are so many that people cannot use a memorable phrase or a manager-generated string, and fall back to the shortest legal string plus a fixed patch. The real password becomes more predictable, not stronger. This entry is about the content and consequence of rules, not about whether they appear early enough, and not about blocking paste. NIST SP 800-63B dropped composition rules from its recommendations in favor of sufficient length and a check against breached corpora, on the strength of this backlash—not on a conversion percentage from one experiment.
Why it happens
People satisfy the checker; they do not maximize entropy. As rules pile up, the human-side space is carved into shapes the checker likes: capital first letter, year at the end, ! as the only symbol. Attacker dictionaries already sort by those shapes. When length is pinned at a minimum, people do not volunteer long passphrases, because every extra constraint demands another revision. Forced periodic change stacks the same mechanism: the new secret is the old one plus one. Over-strict rules also reject a manager’s long random string for “illegal characters,” sending the person back to a short invented one. Strength comes from unpredictability and enough length, not from a list of character classes.
Studying it
Password-usability work uses a generation task plus guessability metrics, not “share that passed the checker” alone.
Independent variables: composition set (length only, length plus classes, plus banned characters and dictionaries), rejection against a breach corpus, forced periodic change. Dependent variables: guessability of generated passwords against policy-aware dictionaries, length distribution, edit distance from the previous password, rejection rate of manager-generated strings.
Lab passwords are not real passwords; guessability is only a relative comparison among conditions in the same sample, not an “online crack rate.” Composition-policy studies (including the CMU line of work) repeatedly see patch structure; cite the mechanism, do not invent their hit rates. Product A/B that only watches registration completion will call a lax policy “smoother” and a strict one “safer” without having measured secret strength.
Where it stops holding
High-assurance systems can keep a length floor plus a breach check without stacking character classes. For legacy protocols that die on short secrets, a length floor is patching the protocol, not a win for composition rules. Where local rules still require “three character classes,” the product must comply, but it can delete extra homemade rules on top of the statutory set. Passkeys and other authenticators do not get stronger via composition copy; stuffing them into the same “complexity” language misleads.
Applying it
- Collapse the choose-password policy to: a minimum length, rejection against a breached-password corpus, allowing spaces and common punctuation; delete “must contain four classes at once” and forced periodic expiry.
- When rejecting, say “appears in a known breach list” or “shorter than N,” not “not complex enough,” which pushes people into patches.
- If leftover compliance still demands character classes, keep only the statutory minimum and let long random manager strings through.
- Verify by sampling newly chosen passwords (after redaction) for end-patches and year patterns; sample again on the same definition after the policy change. Compare with a public policy-aware guessing method relatively; do not publish one internal hit count as an industry figure. Also watch whether manager-generated strings are rejected less often.