ProtemKey

Making strong secrets · 4 min read

Why length beats complexity

Each added character multiplies the search space; each added character class only widens it a little. NIST's 2025 guidance sets a 15-character minimum and bans composition rules.

For years, password advice meant complexity: an uppercase letter, a digit, a symbol, all in a short string. Current guidance turns that around. Length is the main lever, and forcing a mix of character types is now something NIST says verifiers must not do. Here is the arithmetic, and then the reasons it plays out even more strongly with real people.

Two ways to grow a search space

For a randomly generated password, the number of possibilities is (size of the character set) raised to the power of (length). In bits, that is length × log2(set size).

  • Making the set bigger changes the bits per character. Going from lowercase (26) to all printable ASCII (94) raises it from 4.700 to 6.555 bits, a gain of 1.855 bits per character.
  • Making the password longer adds a whole character’s worth of bits each time: 4.700 for lowercase, 6.555 for printable.

Widening the set has a ceiling; there are only 94 printable ASCII characters. Length doesn’t.

Bits of entropy for random passwords: length × log2(characters in the set).
LengthDigits (10)Lowercase (26)Letters (52)Letters + digits (62)All printable ASCII (94)
826.637.645.647.652.4
1033.247.057.059.565.5
1239.956.468.471.578.7
1446.565.879.883.491.8
1653.275.291.295.3104.9
2066.494.0114.0119.1131.1
2479.7112.8136.8142.9157.3

Worked example: 8 complex characters versus 16 lowercase letters

Password made of Possibilities Bits Average time at 10^11 guesses/s (fast hash)
8 random printable characters (94) 94^8 ≈ 6.1 × 10^15 52.44 about 8.5 hours
15 random lowercase letters (26) 26^15 ≈ 1.7 × 10^21 70.51 about 266 years
16 random lowercase letters (26) 26^16 ≈ 4.4 × 10^22 75.21 about 6,900 years

The 16-letter password uses only lowercase, the “weakest” set, and still has 22.77 more bits than the 8-character one with every symbol on the keyboard. That is a factor of about 7 million (2^22.77). The 10^11 rate is this site’s illustrative assumption for a fast, unsalted hash on a high-end GPU rig, not a measurement:

Illustrative attack rates used throughout this site. They are order-of-magnitude assumptions, not measurements; real rates vary with hardware, hash settings and defenses.
ScenarioRate (assumed)Situation
Online, rate-limited100 guesses per houra login form that slows down or locks out repeated failures
Offline, slow hash10,000 guesses per seconda stolen database hashed with a deliberately slow, salted scheme (bcrypt class)
Offline, fast hash100 billion guesses per seconda stolen database hashed with a fast unsalted hash (MD5, SHA-1 or NTLM class) on a high-end GPU rig

What NIST SP 800-63B-4 says

NIST’s Digital Identity Guidelines, finalized in August 2025 as SP 800-63B-4, set these requirements for password verifiers (the services that check your password):

  • Length. “Verifiers and CSPs SHALL require passwords that are used as a single-factor authentication mechanism to be a minimum of 15 characters in length.” Passwords used only as part of multi-factor authentication may be shorter, but at least eight characters.
  • Maximum length. “Verifiers and CSPs SHOULD permit a maximum password length of at least 64 characters.”
  • Composition rules. “Verifiers and CSPs SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords.”
  • Blocklists instead. Verifiers must compare a new password against “a blocklist that contains known commonly used, expected, or compromised passwords” and reject matches.

The earlier 2017 revision, SP 800-63B, was the first to drop composition rules and forced periodic changes. The 2025 revision keeps that position and raises the minimum for a password used on its own to 15 characters.

Why complexity rules work worse with people

The table above assumes a computer picked every character. Complexity rules are usually applied to passwords people pick, and people respond to them predictably. NIST’s Appendix A, “Strength of Passwords,” gives the classic example:

“For example, a user who might have chosen “password” as their password would be relatively likely to choose “Password1” if required to include an uppercase letter and a number or “Password1!” if a symbol is also required.”

Password1! is 10 characters and contains lowercase, uppercase, a digit and a symbol. A naive count would credit it with 10 × 6.555 = 65.55 bits. In reality it is one of the first things a guessing attack tries, because the capital goes at the start, the digit and symbol at the end, and the base is a dictionary word. NIST continues: attackers “are likely to guess passwords that have previously proven successful,” and it names “Password1!” as exactly that kind of password. The study NIST cites for the predictable response, Weir and colleagues (2010), tested policies by attacking large sets of real leaked passwords.

Appendix A also notes the usability cost: “analyses of breached password databases reveal that the benefit of such rules is less significant than initially thought,” while “the impacts on usability and memorability are severe.” Its summary adds that users “often work around these restrictions counterproductively.”

Length works with people too

Length requirements don’t prevent bad choices on their own, which is why NIST pairs them with blocklists. But a 15-character minimum pushes people toward phrases rather than decorated single words, and phrases are where length is cheapest to remember. Appendix A: “The use of passphrases (i.e., passwords with multiple words) is often an effective way to create a longer password.”

A random passphrase gets the best of both. Four EFF words average about 28 letters plus separators, comfortably over 15, at 51.70 bits; six words reach 77.55 bits. See how passphrases work.

When complexity still matters

Character variety is not useless; it just isn’t the efficient lever.

  • When length is capped. If a site limits passwords to, say, 16 characters, using all 94 printable characters gives 104.87 bits instead of 75.21 for lowercase only. That is the main case where widening the set pays off.
  • When a site demands it. Many sites still require a digit or symbol. A random generator can satisfy such rules with almost no loss: the password generator counts the exact number of strings that meet an “at least one of each” rule and reports those bits.

Note: All of this concerns guessing. Length doesn’t help if a password is reused, phished, or stored in plain text by the service. NIST’s Appendix A says as much: phishing and keystroke logging “are equally effective on lengthy and complex passwords as they are on simple ones.”

For the rules that do the most harm, see password rules that backfire; for why some passwords are guessed first, see what makes a password common.

Sources

  1. NIST SP 800-63B-4, Digital Identity Guidelines: Authentication and Authenticator Management (2025)
  2. Weir, Aggarwal, Collins, Stern (2010), Testing Metrics for Password Creation Policies by Attacking Large Sets of Revealed Passwords, ACM CCS

General explanation, not advice for a particular situation. Updated 2026-10-31.