Password composition rules: why “one number, one symbol” backfires

What it is

Composition rules are the checklist under a password field: minimum eight characters, at least one uppercase letter, at least one digit, at least one symbol, and often a ban on characters the back end cannot handle. The intent is to force variety into passwords so that an attacker guessing common words gets nowhere.

The problem is that a rule constrains everybody the same way. Told to add a digit, a large share of people add “1” at the end. Told to add an uppercase letter, they capitalise the first character. Told to add a symbol, they add “!”. The rule does not spread passwords out across the space of possible strings; it concentrates them in the corner of that space that satisfies the rule with the least effort. An attacker who knows your policy — and the policy is printed next to the field — can generate candidates in exactly that shape.

NIST Special Publication 800-63B-4, published in July 2025, states in section 3.1.1.2 that verifiers and credential service providers “SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords”, and separately that they “SHALL NOT require subscribers to change passwords periodically”. The same section requires screening new passwords against a blocklist of known commonly used, expected, or compromised values. It is worth being precise about the status of that document: SP 800-63B-4 is a US federal guideline, binding on federal agencies and the systems that serve them, and widely adopted voluntarily elsewhere. It is not a law that applies to every website.

The game level built on this idea, Password Paradox, exaggerates one specific failure mode: the requirement list rotates every few seconds, and most of the sets it shows are mutually unsatisfiable. Only occasionally does a coherent set appear — one wants at least eight characters including a Cyrillic letter, a number and a symbol; another wants exactly eight characters with upper case, lower case and a digit. The player has to notice a satisfiable window and type inside it. That is a caricature, but the feeling it produces is the ordinary feeling of a real password form whose rules are revealed one rejection at a time.

Why it works on people

Composition rules survive because they are cheap to implement, easy to audit, and produce a satisfying green checklist. A regular expression is a deliverable. “We screen against 600 million breached passwords” requires a data source and a lookup budget, and it leaves nothing for a compliance checklist to tick.

They also survive because their cost lands on someone else. The organisation sees a policy applied; the user absorbs the memory load. Inglesant and Sasse studied this directly, asking 32 staff across two organisations to keep a password diary for a week and then interviewing them about each of the 196 passwords recorded. Their finding was that people generally do want to be secure, but that inflexible policies exceed what they can manage in the contexts where they actually work — so the effort reappears as reuse across systems, as written-down passwords, and as lost time.

The strongest single piece of evidence against character-class rules is Komanduri and colleagues’ study of more than 5,000 participants, presented at CHI 2011. They compared a policy requiring only sixteen characters against one requiring eight characters plus an uppercase letter, a number, a symbol and a dictionary check. The guidelines of the day predicted roughly equal entropy. What they measured was that the sixteen-character policy “yields significantly less predictable passwords, and that it is, by several metrics, less onerous for users”. Length was both stronger and easier.

There is a second-order effect that composition rules produce almost by design. A password the user cannot hold in memory has to be stored somewhere. If the interface also blocks pasting, what remains is a note on a desk, a reused password, or a predictable variation on last quarter’s. The policy pushes people toward the behaviours it was written to prevent.

Where you meet it

• A signup form that reveals its rules only after the first submission fails, so the user discovers the symbol requirement by being rejected.
• A rule set that contradicts itself in practice — a symbol is required, but a specific list of symbols is silently rejected by the back end, producing an error that names no cause.
• A maximum length so short that a passphrase or a password manager’s generated string will not fit, which usually indicates the password is being stored or transported in a fixed-width field.
• A field that blocks paste, or strips characters after the paste, so a generated 32-character password is silently truncated and the account is created with a credential the user has no copy of.
• Ninety-day forced rotation, which reliably produces the same root with an incrementing suffix, and which current NIST guidance advises against as a routine practice.
• A strength meter driven by character classes rather than guessability, so “P@ssw0rd1” scores as strong and a long, unusual phrase of lowercase words scores as weak.
• Security questions used as a fallback, which lower the effective strength of the account to whatever the answer is worth.

Designing around it

• Require length, not composition. SP 800-63B-4 section 3.1.1.2 requires a minimum of 15 characters for a password used as a single factor, permits a minimum of 8 when the password is only ever one factor within a multi-factor flow, and says verifiers should permit a maximum length of at least 64 characters. Set the floor with the minlength attribute on the input so the browser can enforce it, and either omit maxlength or set it no lower than 64 — a maxlength of 20 is a data-model decision leaking into a security control.
• Screen against a compromised-password list at set time and at change time. This is the requirement that replaces composition rules, and it is where the actual protection lives: a password that appears in a public breach corpus is guessable regardless of how many character classes it contains. Reject with a message that says exactly what happened — “this password appears in a list of passwords exposed in known breaches, please choose another” — rather than a generic “password not allowed”.
• Accept the full Unicode range and treat every character as one character. SP 800-63B-4 says verifiers should accept Unicode characters in passwords; spaces, emoji and non-Latin scripts are all legitimate. If your storage or normalisation genuinely cannot handle something, reject it loudly at the point of entry. Silently stripping characters is worse than rejecting them, because the user leaves believing in a password that no longer exists.
• Show the rules before the field, all at once, and never change them mid-entry. Put the requirements in their own element and reference it from the input with aria-describedby, so a screen reader user hears the rules as part of the field rather than having to hunt for them. Live validation belongs in a separate element with role="status" so updates are announced politely; announcing on every keystroke is noise, so debounce it and announce state changes rather than character counts.
• Make password managers work. Use type="password" with autocomplete="new-password" on registration and change forms, and autocomplete="current-password" on sign-in, so managers fill and save the right value; put a stable id on the field and a real label element pointing at it. Do not intercept paste — SP 800-63B-4 says verifiers should permit the paste function specifically to facilitate password manager use. Offer a show-password toggle as a real button with aria-pressed reflecting its state, rather than only masking.
• Drop scheduled rotation and rotate on evidence instead. Force a change when there is a signal — a credential appears in a breach corpus, an account shows signs of compromise, an administrator requests it. That is a smaller number of forced changes, each of which has a reason you can state to the user.
• Move strength feedback from classes to guessability. A meter that estimates how many guesses a password would survive will rate a long ordinary phrase above a short scrambled one, which is the ranking that matches the evidence. Whatever meter you use, treat it as advice; the hard gate should be length plus the blocklist.
• Test the rejection path, not just the happy path. Register with a 64-character generated string, with a passphrase containing spaces, with emoji, with a Cyrillic or CJK character, and with a known-breached password. Then try each one again through the password-reset flow — reset forms are frequently a separate implementation with a stricter, older rule set, and that mismatch locks people out of their own accounts.

Questions

Why are password composition rules considered harmful?

Because they push everyone toward the same few ways of satisfying them, which narrows rather than widens the space an attacker must search. A rule demanding a digit and a symbol mostly produces passwords ending in “1!”. Meanwhile the rule adds real memory cost, which people offset by reusing passwords or writing them down.

Does NIST say not to require special characters in passwords?

Yes. NIST SP 800-63B-4, section 3.1.1.2, states that verifiers and credential service providers shall not impose composition rules such as requiring mixtures of different character types. It asks for a length minimum and screening against known-compromised passwords instead. Note that this is guidance binding on US federal systems and voluntary elsewhere, not a universal legal requirement.

Should users be forced to change their passwords every 90 days?

Current NIST guidance says no. SP 800-63B-4 states that verifiers shall not require subscribers to change passwords periodically, and shall force a change when there is evidence of compromise. Scheduled rotation tends to produce incremented variants of the previous password, which offers little protection for a lot of user effort.

What should a password field require instead?

A length floor, a generous ceiling, and a check against known-breached passwords. Accept any character including spaces and emoji, allow pasting so password managers work, use autocomplete="new-password" so they can save the result, and show the rules before the field rather than revealing them through rejections.

Related patterns

• Placeholder text as a label: what breaks and what to do instead
• Pre-selected defaults: when the form has already answered for you
• Hick’s law: the most misquoted number in interface design
• Confirmshaming and the confirmation gauntlet: when “are you sure?” is the trap