Why do websites reject my “strong” password when it looks strong to me? Because “strong to you” (like P@ssw0rd2024!) is weak to the server’s hidden rules: it’s on a blocklist of 10,000 common passwords, it’s been seen 52 million times in breaches, it’s too similar to your email, or it’s too short for that site’s 12-character minimum — and the site checks all of that in 50 ms before it ever hashes. Since 2017, NIST SP 800-63B flipped the old “must have upper+lower+number+symbol” rule to “must be long, must not be on a blocklist of breached/common passwords, and must allow all printable characters.” If your “strong” password is really a common pattern with leet-speak, it will fail every modern check. This guide explains the 5 hidden rules that reject your password, why NIST changed them, how to read the exact rejection message, and how to create one that passes everywhere — with validators from our password generator.
- The 5 hidden checks (all must pass): 1) Length — e.g., 8–64, many now 12+ minimum, 2) Blocklist — not in top 10k common + dictionary, 3) Breached — not in 850M+ Pwned Passwords (HaveIBeenPwned), 4) Not too similar to username/email, 5) Character rules — must allow, not require, all printable (no “must have symbol” per NIST 800-63B-4). See NIST PDF.
- Why “strong-looking” fails:
P@ssw0rd!→ on blocklist + breached 52M times → fails 2 & 3 even though it has upper/lower/number/symbol.qwerty123!→ dictionary + breached → fails. Short + common beats format. - Modern NIST (2017+) vs old: Old: 8 chars + must have upper/lower/number/symbol + expire every 90 days. New: 8–64 (allow up to 64), check against breached/common, allow spaces/symbols, don’t require them, don’t expire unless breached. See NIST 800-63B-4 + OWASP Authentication Cheat Sheet.
- Read the message: “Password is too common” → blocklist/breached; “Add another word” → length; “Too similar to email” → similarity. Don’t just add
!— change the base. - Create one that passes: Use a 16+ random from our password generator (passes length + blocklist + breached), or 4–5 word passphrase (
correct horse battery staplevariant you haven’t used before). Test via Pwned Passwords before submit. See CISA Use Strong Passwords.
Why Your “Strong” Password Feels Strong but Is Weak to Filters
Your brain rates “strong” by how it looks; servers rate by how predictable it is — and predictable fails blocklists and breach checks in 50 ms.
I see this pattern daily: user sets Qwerty123! and sees “Password is too common” — they add !! → Qwerty123!! → still “too common” — because the base qwerty123 is in every dictionary, and adding ! is the exact mutation attackers try first (NIST notes password → Password1! is the predictable response to old complexity rules). Another user sets JohnDoe1990! (name + year + symbol) → “Too similar to username” — the filter checks your email/name substrings, so even with symbol it fails. Both look strong to you, but to the server they’re in the top 10,000.
The server’s hidden scorecard (per NIST + HaveIBeenPwned + CISA):
- Length first: Is it ≥ site minimum (8, 12, or 15)? Many banks now 12+. Short → “Add another word.”
- Blocklist: Is it in top common + dictionary (e.g.,
password, qwerty, 123456, letmeinand leet variants)? See Pwned Passwords top list. - Breached: Has this exact string appeared in any breach (850M+ corpus)?
Password1!→ seen 5M+ times → “This password was exposed in a data breach.” - Similarity: Does it contain username, email local part, or site name?
john1990forjohn@example.com→ fail. - Composition: Does it meet the site’s allowed characters (not required)? Modern sites allow all printable, but reject
<if they sanitize poorly — that’s a site bug, not your fault.
Pass all 5 and you’re in. Fail any one and you’re out — even if you have upper+lower+number+symbol. That’s why “strong-looking” ≠ passing.
The Leet-Speak Trap
Replacing a→@, o→0, s→$ feels clever but is on every cracker’s mangling rule list. P@ssw0rd! is just password with the top 3 substitutions — it’s still in the blocklist and breached 52M times. The fix isn’t more leet, it’s a longer, non-dictionary base.
The 5 Hidden Rules That Reject Your Password (And What Each Message Means)
Learn to read the rejection — it tells you which of the 5 failed, so you fix the right one instead of guessing.
| Rule | What Server Checks | Message You See | Fix |
|---|---|---|---|
| 1. Length | ≥ minimum (8/12/15) and ≤64 | “Add another word” / “Too short” | Use 16+ random or 4+ words |
| 2. Blocklist | Not in top 10k common + dictionary | “Too common” / “Choose a less common password” | Pick non-dictionary, non-pattern |
| 3. Breached | Not in 850M+ Pwned Passwords | “Exposed in a data breach” | Generate new random — don’t tweak old |
| 4. Similarity | Not containing username/email/site | “Too similar to username” | Remove name/year/site |
| 5. Allowed chars | All printable allowed (no “must have”) | “Invalid character” (rare, site bug) | Use allowed set, report bug if needed |
Why “Must Have Upper+Lower+Number+Symbol” Is Old Advice
Old NIST (pre-2017) required that mix, which taught users to do password → Password1! — predictable and still blocklisted. New NIST says: allow long passwords up to 64, check against breached/common, allow all characters (including space), don’t require the mix, and don’t force expiry unless breached. If a site still says “must have upper, lower, number, symbol,” it’s behind 2017 guidance — still pass it, but know it’s not the security win they think; length + unpredictability is. See NIST 800-63B-4 §5.1.1.2 and OWASP.
NIST Old vs New — Why Your 2016 Password Fails in 2026
| Rule | Old (Pre-2017) | New (NIST 800-63B-4, 2024) | What to Do |
|---|---|---|---|
| Length | 8 chars + complexity | 8–64, allow long, 15+ recommended (CISA) | Use 16+ random |
| Complexity | Must have upper+lower+number+symbol | Allow all, don’t require mix | Don’t chase “must have !” |
| Blocklist | Weak (if any) | Must check vs breached/common/dictionary | Test via Pwned Passwords |
| Expiry | Expire every 90 days | Never expire unless breached | Don’t rotate on timer |
| Hints | Password hint allowed | No hints, no “show last 2” | Don’t use hint |
Per NIST PDF §5.1.1.2, verifiers SHALL compare prospective passwords against a list of known breached values — that’s why “strong-looking” still fails: it’s on that list. And per CISA, a strong password is long (16+), random, and unique — not “has a symbol.”
Why Sites Still Show Old Rules
Many sites haven’t updated their UI from pre-2017 — they still say “must have symbol” even though their backend now checks NIST blocklists. You still must pass the UI to submit, so add the required symbol, but know the real test that matters post-submit is the blocklist/breached check. If a site rejects your 20-char random with “must have symbol” but accepts Password1! (which is breached), it’s misconfigured — report it, but comply to get in.
How to Read the Exact Rejection and Fix It (Don’t Just Add “!”)
Don’t add ! to the same base — change the base. Attackers’ mangling rules try !, 1, 123 first — qwerty! → qwerty1! is still dictionary.
| Message | Which Rule Failed | Wrong Fix | Right Fix |
|---|---|---|---|
| “Too common” | Blocklist / breached | password → Password1! | New random base, 16+ chars |
| “Exposed in a breach” | Breached (Pwned) | qwerty123 → qwerty123! | Never reuse that base anywhere |
| “Too similar” | Contains username/email | john1990 → John1990! | Remove name/year/site entirely |
| “Add another word” | Too short | Add 123 | Use 4+ random words or 16 random |
Try it: paste your rejected password into Pwned Passwords — if it says “seen 52M times,” that’s why. The count tells you it’s in every dictionary. Generating a new 16-char random via our password generator gives count 0 — that’s the fix, not tweaking the old.
How to Create a Password That Passes Every Time — 2 Methods That Work
Both pass length + blocklist + breached on first try — pick one and use it via a manager.
| Method | Example | Length | Why It Passes |
|---|---|---|---|
| 16–20 Random | t9&Fq2!pLz8$vB1?qW (generate) | 16–20 | Unpredictable + not in dictionary/breached + long |
| 4–5 Word Passphrase | correct horse battery staple (random words) | ~25–35 | Long + not a phrase — must be random words |
| Weak (fails) | JohnDoe1990! Qwerty123! | 10–12 but | Dictionary + breached + similar |
Generate the random one via our password generator — set 16–20, all character types, copy to manager. For the passphrase, use the generator’s “passphrase” mode with 4–5 words (Diceware) — don’t pick a lyric or quote, random is the point. Both are allowed to be 64 chars and include spaces per NIST — spaces count and help length.
Why “Must Have Symbol” Is Not the Goal
If the site requires a symbol, you must add one to submit, but a 20-char random without a symbol is stronger than Password1! with one. The symbol rule is UI, not security — length + unpredictability is. So generate 16+ random that happens to include a symbol, and you’ll pass both the old UI and the new blocklist.
Why Do Some Sites Still Reject Long Passwords or Spaces? (The Bugs)
Because their backend hasn’t updated since 2012 — they still validate against old rules and even reject valid NIST passwords.
I see three bugs weekly that have nothing to do with your password’s strength:
- Max 12 or 16, not 64: Old code does
if len(pw) > 16: rejectbecause the DB column isVARCHAR(16). Your 20-char random is rejected as “too long,” butPassword1!(10) passes — even though the 20-char is stronger. Report it, but for that site use 16 random (still better thanPassword1!). - Spaces rejected: Code does
password.contains(" ")→ “invalid character” because someone feared SQL injection — even though NIST says allow spaces. A passphrasecorrect horse battery staplefails, butcorrecthorsebatterystaplewithout spaces (same length, harder to remember) passes — you lose the memorability win. For those sites, use 16 random without spaces, not a short “strong-looking” one. - “<” or “&” rejected: Overzealous HTML escaping rejects
<in passwords, even though passwords are not HTML. Yourp@ss<wordfails, butp@sswordpasses — yet both are equally unpredictable to a cracker. This is a site bug — the password should be hashed, never rendered as HTML, so escaping is unnecessary.
What to do: for that site, comply to get in (16 random without spaces, no <), but know it’s the site that’s behind, not your password. And never reuse that “dumbed-down” password elsewhere — keep your 20-char random for modern sites. If you run a site, fix the validator: allow 8–64, allow all printable including space, check blocklist/breached, and hash with Argon2 — see OWASP.
How to Report a Buggy Password Policy (And Get It Fixed)
Send the site a 2-line note: “Your password policy rejects valid NIST 800-63B passwords: 20-char random with spaces is rejected as ‘too long/invalid character,’ but Password1! (breached 5M times) is accepted. Per NIST 800-63B-4 §5.1.1.2, please allow 8–64, allow all prints including space, and check vs breached/common.” Most security teams fix it — you just gave them the audit finding they needed. In the meantime, generate a site-specific 16-char that fits their bug, store it in your manager, and keep a different 20-char for everywhere else.
What About “Password Strength Meters” — Can You Trust Them?
No — most meters score format, not blocklist/breached, so they call Password1! “Strong” while the server calls it “Too common.”
Meters that only count length + upper/lower/number/symbol will show 4/4 green for Qwerty123! because it has all four, but the server’s blocklist check fails it in 50 ms. The server is right — Qwerty123! is in every dictionary and breached millions of times. A meter that checks Pwned Passwords would show red. That’s why you should test new passwords via Pwned before you trust a meter — count 0 = not in known breaches, count ≥1 = burned, regardless of what the colored bar says. Our password generator shows Pwned count 0 for every generated password, so the meter and the server agree.
Why “Password Hint” and “Security Questions” Also Cause Rejections
Modern sites reject weak hints and answers for the same blocklist reason. If you set hint “my dog’s name” and password is Bella2024!, the similarity check fails. Security questions like “mother’s maiden name” are blocklisted if the answer is in public records. Per OWASP, hints and KBA (knowledge-based answers) should not be used — they’re guessable. Prefer recovery via email + passkey, not questions.
Why Do Some Sites Lock You Out After 3 “Strong” Tries?
Because they rate-limit guessing, even for “strong” passwords — and a blocklisted password counts as a guess.
After 3–5 failures where the server returned “too common” or “breached,” many sites throttle that IP or account for 15 minutes to stop credential stuffing — even though you were the legitimate user trying variants of the same bad base. The lockout is working as designed: the server can’t tell your Password1! → Password1!! from an attacker’s dictionary, so it treats both as guesses. This is why “tweak the same base” not only fails the blocklist but also triggers a lockout that blocks even the correct next try for a while.
What to do: stop tweaking, generate a fresh 16+ random via our password generator, and wait out the cool-down (or use “Forgot password” to reset, which often bypasses the throttle). For your own site, implement the NIST-recommended approach: check blocklist/breached on the server in 50 ms, but don’t lock out on blocklist failures alone — only on repeated breached attempts from the same IP, and offer a clear message like “This password was exposed in a breach — choose a different, longer one” rather than a generic “invalid” that encourages tweaking. See NIST 800-63B-4 and OWASP for rate-limiting guidance that doesn’t punish the user for the server’s blocklist.
What to Do If You’re Stuck on a Site That Rejects Everything
If a site rejects even a 20-char random with “invalid character,” try a 16-char random using only A–Z a–z 0–9 (no symbols) — some legacy validators reject symbols they shouldn’t. If it still rejects, try 12 characters — the site’s max may be 12 with a misleading “too short” message. Log the exact message and report the bug — you’ve found a site that hasn’t updated since 2012. Meanwhile, generate a site-specific 12-char alphanumeric in your manager and keep a different 20-char for modern sites — never dumb down your master password to fit one buggy site.
Practice Lab — Fix 3 Rejections in 2 Minutes
Lab — in any site’s signup + https://toolwasp.com/password-generator + https://haveibeenpwned.com/Passwords:
1) Try "Qwerty123!" → expect "Too common / exposed" → check Pwned → seen millions → generate 16 random → passes
2) Try "JohnDoe1990!" with email john@example.com → expect "Too similar" → remove name/year → 16 random → passes
3) Try "short1!" (7 chars) → expect "Too short / add another word" → generate 4-word passphrase (28 chars) → passes
4) Check any new password via Pwned → count 0 → submit → success
You just mapped message → rule → right fix (change base, not tweak).
Frequently Asked Questions
Why does my strong password keep getting rejected as “too common”?
Because “strong-looking” (upper+lower+number+symbol) still matches a blocklist entry like Password1! or Qwerty123! that’s in the top 10k common + breached corpus. The server checks that list before checking format — format doesn’t save a common base. Generate a new 16+ random via our password generator and test via Pwned Passwords — count 0 means not in blocklist.
What does “this password was exposed in a data breach” mean?
That exact string appeared in a breach dump ingested by HIBP’s 850M+ corpus — attackers already try it in credential stuffing. Even if you never used it on the breached site, you’re now reusing a known password. Count ≥1 = burned for current use. See Pwned Passwords and NIST 800-63B-4 blocklist rule.
Why does my password need to be so long now?
Because length beats complexity for guessing resistance, per NIST PDF and CISA (16+ recommended). A 12-char random is ~130 bits of entropy; an 8-char leet pattern is ~30 bits despite the symbol. Allow up to 64 and use 16+ or 4+ random words — that’s what modern checks reward.
Can I use spaces in my password?
Yes — NIST says verifiers SHALL allow all printable ASCII and spaces. A passphrase like correct horse battery staple is valid and long. If a site rejects spaces, it’s behind 2017 guidance — report it, but use a 16+ random without spaces to get in for now.
Why does it say “too similar to username or email”?
The server checks substrings of your username/email/site name inside the password — john1990 for john@example.com fails even with !. Remove name, year, site, and 3-char sequences from those. Generate a random that has nothing to do with you — that’s the point per OWASP.
Do I really need a unique password for every site?
Yes — reuse is the #1 breach multiplier. If one site leaks your password, attackers try it everywhere (credential stuffing). Unique 16+ per site via a manager means one leak can’t chain. See Pwned Passwords reuse stats and CISA.
Should I just add “123!” to make it pass?
No — mangling rules try 1, 12, 123, !, 1!, 123! first — qwerty → qwerty123! is still dictionary. Change the base entirely to a new random or 4-word phrase. Adding a suffix is the predictable response NIST warned about.
How can I test if my new password will be rejected before I submit?
Paste it into Pwned Passwords (k-anonymity, only 5 hash chars leave) — if count ≥1, pick another. For length/similarity, try our password generator set to 16+ — it generates outside blocklists and checks length — then submit. The site’s own “password strength” meter is often wrong; Pwned is the source of truth for breached.
Last updated: September 3, 2026 • Author: Toolwasp Team • Sources verified Sep 3, 2026: NIST 800-63B-4, NIST PDF, CISA Use Strong Passwords, Pwned Passwords, OWASP Authentication Cheat Sheet. More at Toolwasp.
