Special Characters in Passwords — Myths, Realities, and What Actually Matters

The origin of the special character requirement

The requirement to include special characters (!@#$%^&*) in passwords became widespread from a 2003 NIST publication authored by Bill Burr. The guidance recommended mixing uppercase, lowercase, numbers, and symbols. It was adopted by a very large number of organisations' password policies. In 2017, Bill Burr publicly said he regretted much of this guidance, which had been based on very little data and had produced predictable, unhelpful user behaviour rather than stronger passwords. NIST has since moved away from it: SP 800-63B (2017) advised against composition rules, and the 2025 revision (SP 800-63B-4) states that services must not impose them.

What special characters actually add

Mathematically, adding a required symbol character set of 32 characters to a password's possible character space does increase entropy. A character drawn from all printable ASCII characters (95 options) has more entropy than one drawn from only lowercase letters (26 options). A 12-character password from the full 95-character ASCII set has approximately 78.8 bits of entropy, versus 56.4 bits from lowercase only. This is real — the question is whether real-world password behaviour captures this theoretical benefit.

Why the theoretical benefit rarely materialises

Humans are not random number generators. When told "include a special character," users predictably respond by appending "!" to the end, replacing "a" with "@", "e" with "3", "o" with "0", and "s" with "$". These transformations are so predictable that modern password crackers explicitly test for them. A dictionary attack on "password" will automatically also test "p@ssw0rd", "P@ssw0rd!", "P@$$w0rd", and hundreds of similar leet-speak variations. The "special character" in these passwords adds essentially zero security against a dictionary attack because the crack wordlist includes the leet variations by default.

The research evidence: length beats forced complexity

Research and current NIST guidance point to the same conclusion: length contributes more to password security than forced character complexity, for the simple reason that humans can choose longer passwords without predictable patterns, whereas complexity requirements produce predictable patterns. A genuinely random 20-character lowercase password has more entropy (94 bits) than a 12-character password forced to include uppercase, lowercase, digits, and symbols if the latter is constructed by a human following predictable substitution patterns. The actual entropy of "P@ssw0rd!" is far lower than its character set suggests because humans did not select those characters randomly.

When special characters do help

Special characters genuinely increase security in two scenarios. First: when the password is generated randomly (not by a human choosing which substitutions to make). A truly random 16-character password that happens to include special characters is stronger than a 16-character random password without them, because each character is independently drawn from a larger set. This is why password generators should include all character classes. Second: when the site's maximum length is very short. If a site limits passwords to 8 characters, forcing special characters is the only available lever to increase the search space. NIST recommends that services accept passwords of at least 64 characters, which also spares users from this trade-off.

What actually makes passwords stronger

Length. Randomness. Uniqueness. A 20-character randomly generated password from a generator — whether or not it contains special characters — is vastly stronger than "P@ssw0rd1!" because the latter was constructed by a human following patterns that crack tools know about. The practical implication: use a password generator (like Universal Password Generator) that produces truly random passwords of 16-20+ characters. Do not try to construct passwords manually that "look" complex — "complex-looking" and "actually strong" are not the same thing. If a site does not allow special characters, a long random password without them is still strong. If a site requires special characters, use a generator that includes them — do not add "!" manually to an otherwise weak password.

The arithmetic behind "length beats complexity"

Each additional random character from the full 95-character printable set adds about 6.57 bits, while each additional random lowercase letter adds about 4.70 bits. That means an 8-character password using every character class (about 52.6 bits) is weaker than 16 random lowercase letters (about 75.2 bits), even though the second looks plain. NIST's 2025 guidelines reflect this thinking: a password that is the only authentication factor must be at least 15 characters long, and no mixture of character types is required. In practice, that means a long passphrase or a long generated password is the better investment than hunting for one more symbol to squeeze into a short one. Add symbols when a generator does it for you, and let length do the heavy lifting.