What is the difference between password similarity blocking and a basic compromised-password blacklist?

A basic compromised-password blacklist only blocks exact known bad passwords from a list, while password similarity blocking also catches close variants of a previous password. That matters because attackers often try one-character changes, case shifts, transpositions, and simple substitutions. Similarity controls reduce predictable reuse patterns and make it harder for an exposed password to be turned into an acceptable new one.

Why Password Similarity Blocking Exists

password similarity blocking is an access-control safeguard, not just a stronger version of a blacklist. A compromised-password blacklist only rejects exact matches against a known bad set, so it misses the most common “near reuse” patterns people try after being prompted to change a password. Similarity controls close that gap by comparing the new password against the prior password and rejecting trivial transformations that preserve the same secret with only cosmetic edits.

This matters because users under time pressure often make predictable edits such as appending a number, swapping one character, or changing case. Those changes may satisfy a basic blacklist while still leaving the account exposed to guessing or replay-style abuse. The control is therefore about reducing predictable password evolution, not merely filtering a published breach list. In practice, many teams discover the weakness only after password reset behaviour has already become a routine bypass path.

How It Works in Practice

A basic compromised-password blacklist checks the candidate password against a list of known-bad values. If the exact string appears, it is rejected. That list may come from breach corpora, threat intelligence, or an internal policy set, but the decision logic is still binary and exact-match based.

Password similarity blocking adds a second test: it compares the candidate password to the user’s existing or recently used password and rejects close variants. The control typically looks for small edits that do not materially change the secret, such as:

one-character substitutions or omissions
case changes that preserve the same base word
transposed characters
common suffixes such as digits or symbols added to the old password
simple prefixing or reordering that keeps the same password stem

That distinction changes the security outcome. A blacklist answers “Is this exact password known to be bad?” Similarity blocking answers “Is this effectively the same password as before?” The second question is stricter and better aligned to the real user behaviour that attackers predict. It is especially useful where a password change is forced after suspected exposure, because the control prevents an attacker from taking a guessed or disclosed password and rotating it into a barely altered new value.

In strong implementations, similarity checking sits alongside minimum length, breached-password screening, and password history rules, rather than replacing them. The best results come when the rule is explicit enough to stop trivial reuse but not so aggressive that it blocks legitimate password creativity. These controls tend to break down when policies are tuned only for compliance language and not for the actual ways users recycle passwords.

Common Variations and Edge Cases

Tighter password-change rules often increase user friction, so teams have to balance reuse prevention against support burden and reset failure rates. The practical question is not whether to block every resemblance, but how much similarity still represents a meaningful reuse risk in the organisation’s environment.

There is also a difference between “similar to the old password” and “similar to a known breached password.” Some systems compare only against the user’s recent password history, while others also apply a blacklist of compromised secrets. The strongest policy usually combines both, because they answer different failure modes: one prevents local reuse, the other prevents adoption of a password already exposed elsewhere.

Another edge case is password policy tuning across diverse user populations. For example, a very strict similarity threshold can frustrate password managers that generate human-rememberable passphrases with minor edits, while a weak threshold can still permit obvious variants. Organisations should define the similarity rule in terms of observable reuse patterns, then test it against common change behaviours before rolling it out broadly.

Risk and Threat Considerations

The security risk is password recycling after exposure, especially when users try to satisfy a change prompt with a near-duplicate of the previous secret. A basic blacklist reduces exposure to known compromised values, but it does not stop trivial modifications that remain guessable and operationally close to the old password.

Failure mechanism: An attacker who has an old password, or can predict the user’s change pattern, may try the prior password plus a small variation. If the system only checks for exact blacklist matches, the change is accepted even though the effective secret has barely changed.

Impact: The account remains vulnerable to re-entry, repeated guessing, and faster compromise recovery, because the organisation has allowed a recycled password to pass policy while believing the reset closed the risk.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-63 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST SP 800-63	5.1.1.2 — Memorized Secret Verifiers	Covers password screening and verifier rules for memorized secrets.
Recommendation — Apply memorized-secret screening to reject weak or reused passwords.
CIS Controls v8	5 — Account Management	Addresses password reuse and account credential governance.
Recommendation — Enforce account credential rules that block reused or compromised passwords.
OWASP Non-Human Identity Top 10	NHI-03 — Secret Reuse and Rotation	Reinforces blocking reused secrets and compromised credential patterns.
Recommendation — Prevent secret reuse and rotate credentials that show reuse risk.

Practitioner Guidance

What to prioritise: Treat similarity blocking as part of password reuse prevention, not as a cosmetic policy enhancement. If users are being forced to change passwords after exposure, this control should be tuned before enforcement is tightened elsewhere, because it closes the most predictable bypass path.

What to verify: Confirm that your implementation compares against the prior password and recent history, not just against a breach list. Also verify which edits are considered “similar enough” to reject, because overly narrow rules create a false sense of protection while overly broad rules can drive helpdesk overrides.

Decision rule: If the goal is to prevent an exposed password from being turned into an acceptable new password, use similarity blocking plus breached-password screening. If the goal is only to stop exact reuse of known-bad strings, a blacklist is insufficient on its own.

Practitioner takeaway: The real test is whether the policy stops a user from turning a bad password into a slightly different bad password, because that is where basic blacklists are weakest.