ASVS V6.2.11 requires that the documented list of context specific words, from V6.1.2, is actually used to stop easy to guess passwords being created. It is a Level 2 requirement.
A document alone does not count. The check has to run when someone sets a password.
Documentation without enforcement is a promise you do not keep. This requirement turns the list from V6.1.2 into a working check.
Why it matters
Targeted guessing starts with your company and product names. This control closes the gap that generic breach lists leave.
Generic blocklists contain millions of passwords but rarely your product name. A user who sets a password based on the company name will pass every public check and still be an easy target for anyone doing basic research on the organization. Context aware rules close that hole at almost no cost.
How to implement it
Normalize the candidate, undo common substitutions, and look for list words as substrings.
import re
from pathlib import Path
WORDS = [w.strip().lower() for w in Path("context-words.txt").read_text().splitlines()
if w.strip() and not w.startswith("#")]
SUBS = str.maketrans("4@3180$5", "aaeiloss")
def contains_context_word(pw: str) -> bool:
norm = re.sub(r"[^a-z]", "", pw.lower().translate(SUBS))
return any(w in norm for w in WORDS)
Keep the minimum word length at 4 or more to avoid false positives on short entries, and tell the user which rule fired.
Keep the check separate from the rest of the validator so security can update the list without a code deploy, for example by loading a file at startup or from configuration storage with a reload endpoint protected by admin rights. Log the rule name that fired, never the password, so you can see how often it triggers. For multi tenant products, consider a per tenant list that adds that customer name to the global one.
How to test it
Try Acme2026, 4cm3-Cl0ud! and my-projectfalcon-pass at registration. Each must be rejected. Then try a random passphrase that has nothing to do with your list and confirm acceptance.
Common mistakes
-
Matching only the exact word with no substitutions.
-
Treating a very short entry as a substring and blocking everything.
-
Running the check on registration but not on password change or reset.
-
Matching against the username and email local part only. Add them, but also keep organization words.
-
Reporting the exact blocked word in an error message for public sign up, which lets attackers learn your internal codenames. Use a generic message there.
Quick check
Where must the check run?
Every path that sets a password: registration, change and reset.
