Check Your Password Against the New NIST Rules

Check Your Password Against the New NIST Rules

Check your own password above against the federal publication that most enterprise, government, and increasingly consumer services build their rules from: NIST Special Publication 800-63-4, whose current revision breaks sharply from decades of composition-rule orthodoxy. Verifiers SHALL require at least eight characters for passwords used inside multi-factor authentication, and SHALL require at least fifteen characters for passwords carrying authentication alone as a single factor. Composition mandates, forcing a mix of uppercase, lowercase, digits, and symbols, are explicitly prohibited, and periodic forced rotation is prohibited too, unless there is specific evidence of compromise. In their place, NIST requires screening new passwords against a blocklist of known breached and commonly used credentials, and this page walks through what changed, why the guidance shifted this direction, and how it applies to whatever you just checked above.

The length requirements, word for word

NIST SP 800-63-4 Section 3.1.1.2 states it plainly: 'Verifiers and CSPs SHALL require passwords that are used as a single-factor authentication mechanism to be a minimum of 15 characters in length,' while passwords used only as part of multi-factor authentication may be shorter but SHALL still reach a minimum of eight characters.¹ On the other end, verifiers SHOULD permit a maximum length of at least 64 characters, removing the artificially low caps some older systems still enforce.²

What else the standard says about maximum length

NIST also recommends that verifiers SHOULD allow passwords as long as 64 characters or more, explicitly rejecting the artificially low caps older systems impose. The standard further says verifiers SHOULD accept all printing ASCII characters and the space character, and SHOULD accept Unicode characters as well, counting each Unicode code point as a single character when evaluating length.² The goal is practical flexibility rather than pedantry: if a password manager generates a thirty-character passphrase, the backend should not silently truncate it.

That fifteen-character figure is not arbitrary. At the full 95-character printable ASCII pool, fifteen characters yields roughly 98.5 bits of entropy, comfortably clearing what current GPU-based cracking can reach within any realistic timeframe against a properly hashed password.³ Because the eight-character multi-factor floor and the fifteen-character single-factor floor apply to different threat models, a system that already enforces a second factor is not obligated to also push every user toward the longer figure, though doing so still adds a meaningful safety margin.

Why composition rules got dropped

For years, policies forced you to include an uppercase letter, a digit, and a symbol, on the theory that mixed character classes meant unpredictable passwords. NIST now explicitly states that verifiers SHALL NOT impose such composition rules, because the actual effect was the opposite of intended: users respond to composition mandates in extremely predictable ways, capitalizing the first letter, appending '1!' at the end, substituting '@' for 'a'.⁴

Length beats complexity, by the numbers

The math backs this up directly. A sixteen-character password using only lowercase letters carries roughly 75.2 bits of entropy. An eight-character password forced through a full composition rule, drawing from the 95-character pool, carries only about 52.6 bits, some 23 bits less despite following every complexity rule imposed on it. Length alone, even with a smaller character pool, outperforms complexity squeezed into a short password almost every time.³

NIST documents this reasoning in Appendix A, Strength of Passwords, which explains how the predictable patterns users create under composition mandates fail to produce the randomness the policy intended.⁴ Teaching users to inject capital letters, digits, and symbols into a short base does not expand keyspace meaningfully if the resulting passwords still cluster around a handful of templates; a password manager-generated random string sidesteps the distraction entirely and lands at higher entropy with less user effort.

Blocklist screening: the new mandatory control

In place of composition rules, NIST requires an active check: 'When processing a request to establish or change a password, verifiers SHALL compare the prospective secret against a blocklist that contains known commonly used, expected, or compromised passwords.'⁵ This targets the actual attack pattern that matters most, credential stuffing and dictionary attacks using real breach data, rather than a proxy metric like character variety that never measured predictability directly.

Why periodic rotation also lost its mandate

Because blocklist screening happens at password creation, it catches exactly the passwords composition rules used to let through unchecked: anything already known to attackers, regardless of how many character classes it technically contains. Periodic rotation is dropped for the same reason forcing composition was dropped; NIST SHALL NOT require it absent specific evidence the password has already been compromised, since routine forced changes push users toward small, predictable variations of their previous password rather than genuinely new ones.¹

When to use this

Reach for this guide when you are setting or auditing a password policy for an application, an internal system, or your own accounts, and want to check a password's bits against the 15-character floor before deciding whether your current rules reflect current best practice. It is also useful context when a service's outdated composition requirements are forcing you into a weaker password than you would otherwise choose. Because the guidance shifted so sharply from decades of prior practice, it also helps to have on hand when explaining to a team or a client why a policy change away from composition rules is not a security regression.

Examples

Why Composition Rules Don't Strengthen Passwords

'Password1!' satisfies almost every composition rule a website can throw at it, and that is precisely the problem. Composition requirements, mandating an uppercase letter, a digit, and a symbol, were designed to force unpredictability into every password. Instead, they trained an entire generation of users toward the same narrow set of workarounds: capitalize the first letter, append a digit, tack a symbol onto the end. Consequently, the passwords composition rules approve of are often more predictable, not less, than a password chosen without any rule at all. NIST's current guidance reflects this directly, prohibiting verifiers from mandating composition rules for exactly this reason.¹ This page explains the psychology behind why composition rules backfire, walks through the entropy math that exposes the gap, and covers what genuinely reduces guessability in their place.

How composition rules create predictable passwords

Told to include a capital letter, most people capitalize the first character, since that is the position where capitalization already feels natural from years of writing sentences. Told to include a digit and a symbol, most people append them at the end, often as a short, memorable sequence like '1!' or '123'. Password cracking tools like zxcvbn check for exactly these patterns first, because they are so widespread that testing them costs almost nothing before falling back to broader brute force, and anyone who has watched a cracking tool rank a 'compliant' password below a longer, simpler one has seen the proxy fail in real time, which is precisely why satisfying a composition checklist says almost nothing about whether a password will hold up under attack.²

XKCD's widely referenced 2011 comic illustrated this with 'Tr0ub4dor&3', a password that satisfies every composition rule yet follows the exact substitution pattern, letter-for-number swaps plus an appended symbol, that cracking dictionaries are specifically built to test before falling back to broader search strategies.³ A composition-compliant password is not automatically an unpredictable one. The comic drove the point home by showing how the substitutions humans make under rule pressure are so consistent across users that attackers can predict them exhaustively with almost no extra search cost beyond the base dictionary pass.

Even the specific substitutions people reach for are predictable across languages and demographics: '@' for 'a', '0' for 'o', '3' for 'e', and '1' or '!' for 'i' show up so consistently in breach data that cracking wordlists apply them as a standard mutation pass against every dictionary word before moving on to anything more exhaustive.²

The entropy math composition rules get wrong

A sixteen-character password using only lowercase letters carries roughly 75.2 bits of entropy under the Shannon formula. An eight-character password that satisfies a full composition rule, upper, lower, digit, and symbol, drawing from the complete 95-character pool, carries only about 52.6 bits, some 23 bits less despite technically following every rule imposed on it. Composition rules optimize for a proxy, character-class variety, that correlates weakly with what actually matters: the size of the keyspace an attacker must search.⁴

Where the proxy breaks down completely

Because composition rules apply to short passwords just as readily as long ones, they let an eight-character password through as 'strong' while providing no mechanism to push users toward the length that would actually matter more. A person satisfying the rule with the shortest possible compliant password gets a worse outcome than someone ignoring the rule entirely and typing sixteen plain lowercase characters instead.

What entropy actually measures here

Entropy measures the size of the search space an attacker must navigate, not whether a character set is diverse. A password that uses only lowercase letters but is long enough still presents more possible combinations than a short, rule-compliant alternative using the full ASCII set, because entropy is additive across character positions under assumed-random selection. Multiplying the pool size by the length gives the total keyspace, which is why an eight-character password drawn from ninety-five symbols can still lose to a sixteen-character password drawn from twenty-six.⁴

The practical lesson is that any entropy calculation stopping at character-class variety misses the larger keyspace that length alone provides, because each additional character multiplies the search space whether or not the character set is more diverse. That is why the tools that rate password strength today prioritize total entropy over rule compliance, and it is why the most effective password policy is to demand length and then let users choose characters freely without enforcing a composition checklist.

What actually reduces guessability

NIST's current guidance replaces composition mandates with two more direct controls: a length requirement, fifteen characters for standalone passwords, and mandatory blocklist screening against known breached and commonly used passwords at the moment a password is created.¹⁵ Both target the actual failure modes composition rules missed, insufficient length and reuse of already-compromised credentials, rather than a proxy metric that predictable substitution patterns can satisfy without any real gain in unpredictability.

For your own passwords, the practical replacement for composition rules is straightforward: favor length over complexity, let a generator produce genuinely random characters rather than typing a rule-compliant pattern by hand, and check new passwords against a breach database before reusing anything close to a previous one. None of this requires memorizing more rules yourself; a password manager's generator already defaults to the full character pool and a comfortable length, and you can score a rule-compliant password's real randomness against that same baseline to see exactly how far short a checklist-satisfying password actually falls.

Why blocklist screening beats composition rules at the source

CapyToolkit applies this reasoning by scoring the actual effective randomness of passwords instead of counting character classes. A password that satisfies every composition rule but appears in a breach list will score poorly under that approach, while a long, randomly generated value from a password manager will score well even if it contains no uppercase letters or symbols at all. Auditing an existing policy against these two controls, rather than against a checklist of required character classes, is the fastest way to tell whether it reflects current thinking.

When to use this

Reference this page when a service still enforces old-style composition requirements and you want to understand why following them does not guarantee a strong password, or when you are designing a signup form and deciding whether to keep composition rules your organization inherited from an older policy.

Examples