Skip to main content
Identity Authority
Category: Passwords & Hashing

Password Blocklist

Also known as: Password Blacklist, Banned Password List
Simply put

A password blocklist is a list of passwords that users are not allowed to choose, typically because they are common, previously leaked, or easily guessed. When someone tries to set or change their password, the system checks it against this list and rejects any match. This helps prevent people from picking weak passwords that attackers could readily guess.

Formal definition

A password blocklist is a knowledge-factor policy control applied during credential registration and update flows that rejects candidate passwords matching entries on a defined list of prohibited values, commonly including dictionary words, known-compromised credentials, and easily guessed terms. It is enforced at password-set and password-change time as part of the authentication credential lifecycle, not at authentication runtime for existing valid credentials. Implementations vary by vendor and configuration: some support custom lists with capacity limits (for example, Microsoft Entra ID caps its custom banned password list at 1,000 terms and notes it is not designed for very large lists), while others integrate breach-corpus or dictionary-based checks; matching behavior such as case handling, substring or fuzzy matching, and normalization depends on the specific product profile. This control addresses password strength policy and is distinct from authorization decisions and from broader identity governance concerns such as access certification.

Why it matters

Password blocklists address one of the most persistent weaknesses in knowledge-factor authentication: users tend to choose predictable passwords that appear in common dictionaries or in known-compromised credential corpora. Attackers exploit this directly through password spraying and credential-based guessing, where a small set of high-frequency passwords is tried against many accounts. By rejecting these values at the point where a password is set or changed, a blocklist removes the weakest candidates before they ever become live credentials, raising the baseline quality of passwords across a user population.

Because the control operates during credential registration and update rather than at authentication runtime, it is preventive rather than reactive. It does not evaluate or invalidate existing valid credentials during sign-in; instead it shapes what credentials can exist in the first place. This distinction matters for planning: organizations that adopt a blocklist should account for the fact that already-set weak passwords remain until the next password change unless a separate remediation process forces rotation.

Blocklists are a complement to, not a substitute for, other authentication strengthening measures such as MFA and passwordless approaches. They reduce the risk associated with a single knowledge factor but do not eliminate the inherent limitations of passwords as a factor. Treating a blocklist as one layer within a broader authentication strategy avoids over-reliance on password strength policy alone.

Who it's relevant to

IAM Engineers
Engineers configuring password policy need to understand where blocklist enforcement sits in the credential lifecycle, at password-set and password-change time, not at runtime authentication. They should verify implementation-specific behavior such as list capacity, matching rules, and normalization, since these vary by vendor. For example, Microsoft Entra ID's custom banned password list is limited to 1,000 terms, which constrains how custom lists can be used relative to breach-corpus or dictionary-based checks.
Security Architects
Architects positioning a blocklist within a broader authentication strategy should treat it as one preventive layer for the knowledge factor rather than a standalone defense. It reduces exposure to guessing and spraying attacks against weak passwords but does not replace MFA or passwordless approaches, and it does not remediate existing weak credentials that predate the policy.
System Administrators
Administrators managing platforms such as Keycloak, Microsoft Entra ID, or similar systems are responsible for enabling and maintaining blocklist configuration, including any custom lists. They should be aware that capacity limits and matching behavior differ across products and that the control only affects new or changed passwords, so separate action may be needed to force rotation of previously set weak passwords.
Compliance Officers
Compliance leads evaluating password strength controls can treat a blocklist as evidence of a preventive measure against common and known-compromised passwords. They should note that its scope is limited to credential registration and update and is distinct from identity governance concerns such as access certification, and that its effectiveness depends on how the underlying list is sourced and maintained.

Inside Password Blocklist

Compromised credential lists
Collections of passwords known to have appeared in prior breaches or credential dumps, typically aggregated from public and commercial breach corpora. In most deployments these are the primary source feeding the blocklist.
Common and predictable passwords
Frequently chosen strings such as dictionary words, keyboard patterns, seasonal terms, and simple substitutions that users select regardless of any specific breach exposure.
Organization-specific terms
Context-sensitive entries such as company name, product names, and local geographic references that are easily guessed within a given environment. The exact contents depend on configuration.
Normalization and matching logic
Rules that transform a candidate password before comparison, such as case folding, leetspeak substitution reversal, or fuzzy matching, so variants of a blocked term are also rejected. Behavior varies by vendor and configuration.
Comparison mechanism
The method used to check a candidate against the list, which may involve local storage, hashed lookups, or an external service query. This is a knowledge-factor credential control and does not affect authentication factors such as possession or inherence.

Common questions

Answers to the questions practitioners most commonly ask about Password Blocklist.

Does a password blocklist mean users can just add numbers or symbols to a banned password to get around it?
That depends on how the blocklist is implemented. A naive exact-match blocklist can often be bypassed by trivial variations, which is why many deployments apply normalization or fuzzy-matching techniques such as case folding, leetspeak substitution reversal, and stripping of common padding before comparing a candidate password against the list. The effectiveness against variation-based bypass is a function of the matching logic, not of the blocklist concept itself, so implementations vary considerably.
Isn't a password blocklist the same thing as traditional password complexity rules?
No. Complexity rules enforce structural requirements such as minimum length or required character classes, whereas a blocklist rejects specific known-weak or compromised passwords regardless of whether they satisfy complexity rules. A password can meet complexity requirements and still appear on a blocklist because it is commonly used or previously breached. The two controls address different problems and are often used together rather than as substitutes.
At what point in the flow should a password be checked against the blocklist?
In most deployments the check is applied at password creation and at password change or reset, so that weak or compromised values are rejected before they are stored. Some implementations also re-evaluate existing passwords against updated blocklists during authentication events or on a scheduled basis, prompting a reset when a match is found. The exact placement depends on the platform and the policy configuration.
How is a blocklist typically stored and queried without exposing the underlying password values?
Approaches vary by implementation. Some systems store hashed representations and compare hashes of candidate passwords, while others use probabilistic structures such as Bloom filters to reduce storage and lookup cost at the expense of a controlled false-positive rate. Where external breach-corpus checks are used, techniques such as k-anonymity range queries can limit how much of the candidate value is exposed. The specific mechanism affects both privacy and performance and should be evaluated for the deployment context.
What are the main sources used to populate a password blocklist?
Blocklists are typically populated from lists of commonly used passwords, dictionary words, organization-specific terms such as company or product names, and credentials known to have appeared in public breach corpora. Some organizations also add context-specific values like usernames or predictable seasonal patterns. The composition of the list is a policy decision and should be reviewed and updated periodically, since a static list loses value as new weak or compromised passwords emerge.
How should a false positive be handled when a legitimate password is rejected?
Because blocklist matching, especially with fuzzy or probabilistic techniques, can reject otherwise acceptable passwords, deployments generally handle this by prompting the user to choose a different value and providing clear guidance without revealing which specific entry was matched, to avoid leaking blocklist contents. Tuning the matching aggressiveness and the acceptable false-positive rate is a trade-off between usability and security that depends on the chosen implementation and organizational risk tolerance.

Common misconceptions

A password blocklist authenticates or authorizes users more securely.
A blocklist is a credential-strength control applied during password creation or change, not an authentication or authorization mechanism. It influences the quality of a knowledge factor but does not verify identity (authentication) or determine permitted actions (authorization).
Composition rules (length, character classes) make a blocklist unnecessary.
Composition rules and blocklists address different problems. Composition rules constrain structure but still permit predictable or already-breached passwords that satisfy them, whereas a blocklist specifically rejects known-weak or known-compromised values. In most deployments the two are complementary rather than substitutes.
Checking against breach data means the plaintext password is exposed.
Depending on configuration, comparisons are typically performed against hashed values or via privacy-preserving lookups so the full plaintext need not be transmitted or stored in clear. However, the exact privacy properties depend on the implementation and should be verified rather than assumed.

Best practices

Enforce the blocklist check at password creation and change time, and consider re-evaluating existing passwords against updated lists during periodic events rather than only at set time.
Combine breach-derived compromised-credential lists with common-password and organization-specific terms so both widely-known and locally predictable values are rejected.
Apply normalization such as case folding and common substitution handling so trivial variants of blocked entries are also caught, but validate the matching behavior against your vendor's documented configuration.
Prefer privacy-preserving comparison methods, such as hashed or partial-hash lookups, and confirm that plaintext passwords are not unnecessarily transmitted or stored.
Keep the blocklist source current by refreshing it as new breach corpora become available, since a stale list loses coverage over time.
Treat the blocklist as a credential-quality control that complements, not replaces, other layers such as MFA and account monitoring, and clearly document what it does and does not cover.
Promotional banner for the Penetration Report Template Kit