ASVS V6.2.5 says passwords of any composition must be allowed. You may not require a minimum number of uppercase letters, lowercase letters, digits or special characters. It is a Level 1 requirement.
The rule is about what you must not require. You are free to stop a password for being short, common, breached or tied to your organization. You just cannot demand a mix of character classes.
Why it matters
Composition rules push people toward predictable patterns: a capital first letter, a digit at the end, an exclamation mark. Attackers know this and build their guesses around it. The rules also frustrate users who then reuse one compliant password everywhere.
Research and long experience show that composition rules produce a tiny set of patterns. If a site demands one capital, one digit and one symbol, most people write a word with a capital at the front, a number at the end, and an exclamation mark. Cracking tools try exactly those shapes first.
Rules also create support load, because users forget which variation they used for which site. The result is more resets, more reuse and weaker security.
How to implement it
Replace complexity checks with length and a breached or common list check.
function validatePassword(pw) {
if (pw.length < 15) return "Use at least 15 characters.";
if (isCommon(pw) || isBreached(pw)) return "That password is known from past breaches.";
return null; // no character class requirements
}
Accept spaces, Unicode and emoji. Do not strip or reject characters, which also supports V6.2.8.
Audit three places: the front end form hints, the server side validator and the identity provider settings. Remove complexity requirements from all three, then update the help text. Replace the strength meter with one that rewards length and checks against your lists. If a downstream system still requires symbols, treat that as a defect to fix, or transform the password safely there instead of exposing the rule to users.
How to test it
Submit a 20 character lowercase passphrase, a 20 character all digit string, and a password containing spaces and an accented letter. All must be accepted if they are not on a blocklist. Search the code and UI copy for regexes such as [A-Z] or the words "special character".
Common mistakes
-
Leaving old regex rules in the form validation while the API is relaxed.
-
Blocking spaces.
-
Displaying a strength meter that scores by character classes.
-
Adding a maximum number of repeated characters or sequential characters, which is a composition rule in disguise.
-
Rejecting passwords that contain a space or non ASCII letters because an old database column cannot store them.
Quick check
Can I still reject a password?
Yes, for being too short, common, breached or context specific. Just not for lacking a character class.
