CWE-521 is a product that does not require users to have strong passwords. It is not tied to a language or technology. Any system with password login can have it.
How it happens
The sign-up and reset forms accept whatever is typed. A one character password, password, the user's own name or the app name all pass. Sometimes there is a policy but only in the browser, so a direct request skips it. Sometimes the check is a length minimum alone.
The record has a real example: CVE-2020-4574 is described as a key server application that does not require strong passwords.
# Vulnerable: no policy at all
def set_password(user, new_password):
user.password_hash = hash_password(new_password)
What an attacker gains
MITRE says an attacker can easily guess user passwords and gain access to user accounts. That is gaining privileges or assuming an identity. Weak passwords make guessing, credential stuffing and brute force cheap, and every account becomes a way in.
How to find it
Automated static analysis can find some instances, for example password handling code with no validation step. Also test it directly.
- Try to register or reset to a one character password and to a common one such as
123456. - Send the request straight to the API, skipping the web form, to see whether the rule is enforced on the server.
- Look for a policy that checks only length, or only character classes.
- Check admin and service accounts, which often have separate and weaker rules.
How to fix it
MITRE's guidance is to design the product to require an appropriate password policy. The specifics depend on context, but it recommends these attributes.
- Enforce a minimum and a maximum length.
- Block reuse of earlier passwords.
- Block common passwords.
- Block contextual strings such as the user id or the app name.
Other options depend on your threat model. Complex character mixes make guessing harder but can lead people to short passwords or writing them down, and predictable symbol use limits the gain. A large minimum length that encourages passphrases helps, though picking a good passphrase is not easy, so prompting may be needed. Randomly generated secrets guarantee strength but are hard to memorize.
MITRE points to NIST 800-63B for detail on password requirements, and it suggests a password strength meter to tell users when a choice meets the rules.
Two more points from the record:
- Consider a second authentication factor so the password is not a single point of failure.
- Password expiration on a fixed schedule, such as every 90 days, is now listed as a discouraged common practice, because forced changes often lead to more predictable passwords. Forcing a change when there is evidence of compromise is still encouraged.
COMMON = load_common_passwords() # a list you maintain
def validate_password(pw, user):
if len(pw) < 12 or len(pw) > 128:
return False, "Use 12 to 128 characters."
if pw.lower() in COMMON:
return False, "That password is too common."
for s in (user.username, user.email.split("@")[0], "myapp"):
if s and s.lower() in pw.lower():
return False, "Do not include your name or the app name."
return True, ""
Run this on the server for every set and reset path, not only in the browser.
Quick check
Is a periodic forced password change a good fix?
MITRE lists fixed schedule expiration as a discouraged common practice. Force changes when compromise is suspected instead.
Where must the policy be enforced?
On the server, for every path that sets a password, including resets and APIs.
