CWE-521: Weak Password Requirements

Mitigation Strategies

Phase

Architecture and Design

Description

A product's design should require adherance to an appropriate password policy. Specific password requirements depend strongly on contextual factors, but it is recommended to contain the following attributes: Enforcement of a minimum and maximum length Restrictions against password reuse Restrictions against using common passwords Restrictions against using contextual string in the password (e.g., user id, app name) Depending on the threat model, the password policy may include several additional attributes. Complex passwords requiring mixed character sets (alpha, numeric, special, mixed case) Increasing the range of characters makes the password harder to crack and may be appropriate for systems relying on single factor authentication. Unfortunately, a complex password may be difficult to memorize, encouraging a user to select a short password or to incorrectly manage the password (write it down). Another disadvantage of this approach is that it often does not result in a significant increases in overal password complexity due to people's predictable usage of various symbols. Large Minimum Length (encouraging passphrases instead of passwords) Increasing the number of characters makes the password harder to crack and may be appropriate for systems relying on single factor authentication. A disadvantage of this approach is that selecting a good passphrase is not easy and poor passwords can still be generated. Some prompting may be needed to encourage long un-predictable passwords. Randomly Chosen Secrets Generating a password for the user can help make sure that length and complexity requirements are met, and can result in secure passwords being used. A disadvantage of this approach is that the resulting password or passpharse may be too difficult to memorize, encouraging them to be written down. See NIST 800-63B [REF-1053] for further information on password requirements.

Phase

Architecture and Design

Description

Consider a second authentication factor beyond the password, which prevents the password from being a single point of failure. See CWE-308 for further information.

Phase

Implementation

Description

Consider implementing a password complexity meter to inform users when a chosen password meets the required attributes.

Phase

Implementation

Description

Previously, "password expiration" was widely advocated as a defense-in-depth approach to minimize the risk of weak passwords, and it has become a common practice. Password expiration requires a password to be changed within a fixed time window (such as every 90 days). However, this approach has significant limitations in the current threat landscape, and its utility has been reduced in light of the adoption of related protection mechanisms (such as password complexity and computational effort), along with the recognition that regular password changes often caused users to generate more predictable passwords. As a result, this is now a Discouraged Common Practice [REF-1488] [REF-1489], especially as the sole factor in protecting passwords. It is still strongly encouraged to force password changes in case of evidence of compromise, but this is not the same as a forced "expiration" on an arbitrary time frame.

Source-backed guidance

Additional facts reviewed against primary or authoritative security sources.

Verify controls for CWE-521 with SSDF evidence

Use NIST SSDF verification and vulnerability-response practices to detect CWE-521, Weak Password Requirements, throughout the product lifecycle. Derive review questions, static or dynamic checks, and negative tests from the CWE's causal behavior; define the components and lifecycle stages each check covers; and retain findings with enough evidence to distinguish the root cause from symptoms and impacts. Track escapes and false negatives, then improve the verification plan after every confirmed occurrence.

NIST SP 800-218 Secure Software Development Framework — National Institute of Standards and Technology

Address Weak Password Requirements during Architecture and Design

MITRE associates mitigation with Architecture and Design, and Implementation; documented detection approaches include Automated Static Analysis; recorded impacts include Gain Privileges or Assume Identity. Use these source-defined anchors to turn CWE-521 into implementation, review, and verification checks for the affected component.

CWE-521: Weak Password Requirements — MITRE CWE

Triage CWE-521 against known exploitation evidence

Use CISA's Known Exploited Vulnerabilities catalog to test whether a vulnerability mapped to CWE-521, Weak Password Requirements, has evidence of exploitation in the wild. Confirm the CVE-to-CWE root-cause mapping independently before attaching the example, then capture the affected product, required action, and remediation deadline. A missing KEV match is not evidence that the weakness is unexploited, and a KEV entry must not be generalized to every occurrence of this CWE.

Known Exploited Vulnerabilities Catalog — Cybersecurity and Infrastructure Security Agency

Apply precise root-cause mapping to CWE-521

Apply MITRE's full root-cause mapping guidance when using CWE-521, Weak Password Requirements. Separate weakness language from attacker prerequisites and technical impact, check the entry's abstraction and vulnerability-mapping notes, and prefer the most specific Base or Variant supported by the evidence. Record the rejected alternatives and require an independent review before the mapping is used for remediation trends or program metrics.

CVE to CWE Root Cause Mapping Guidance — MITRE CWE

Validate CWE-521 with root-cause mapping checks

Apply MITRE's root-cause mapping quick tips to CWE-521, Weak Password Requirements. Confirm the finding describes the causal weakness rather than an impact or attack pattern, compare the abstraction and mapping notes with plausible alternatives, and have a second reviewer challenge the selection. Preserve the evidence and reasoning so recurring defects can be measured against one consistent identifier.

CVE to CWE Root Cause Mapping Quick Tips — MITRE CWE

Frequently Asked Questions

What is CWE-521: Weak Password Requirements?+

CWE-521: Weak Password Requirements is a Common Weakness Enumeration (CWE) entry maintained by MITRE. The product does not require that users should have strong passwords.

What are the security consequences of Weak Password Requirements?+

If exploited, CWE-521 (Weak Password Requirements) it can compromise Access Control, leading to outcomes such as Gain Privileges or Assume Identity.

How do you prevent or mitigate Weak Password Requirements?+

Recommended mitigations for CWE-521 include: A product's design should require adherance to an appropriate password policy. Specific password requirements depend strongly on contextual factors, but it is recommended to contain the following attributes: Enforcement of a minimum and maximum length Restrictions against password reuse Restrictions against using common passwords Restrictions against using contextual string in the password (e.g., user id, app name) Depending on the threat model, the password policy may include several additional attributes. Complex passwords requiring mixed character sets (alpha, numeric, special, mixed case) Increasing the range of characters makes the password harder to crack and may be appropriate for systems relying on single factor authentication. Unfortunately, a complex password may be difficult to memorize, encouraging a user to select a short password or to incorrectly manage the password (write it down). Another disadvantage of this approach is that it often does not result in a significant increases in overal password complexity due to people's predictable usage of various symbols. Large Minimum Length (encouraging passphrases instead of passwords) Increasing the number of characters makes the password harder to crack and may be appropriate for systems relying on single factor authentication. A disadvantage of this approach is that selecting a good passphrase is not easy and poor passwords can still be generated. Some prompting may be needed to encourage long un-predictable passwords. Randomly Chosen Secrets Generating a password for the user can help make sure that length and complexity requirements are met, and can result in secure passwords being used. A disadvantage of this approach is that the resulting password or passpharse may be too difficult to memorize, encouraging them to be written down. See NIST 800-63B [REF-1053] for further information on password requirements. Consider a second authentication factor beyond the password, which prevents the password from being a single point of failure. See CWE-308 for further information. Consider implementing a password complexity meter to inform users when a chosen password meets the required attributes.

Which programming languages are affected by Weak Password Requirements?+

CWE-521 commonly affects Not Language-Specific. Note that weaknesses are often language-agnostic patterns, so secure coding practices apply broadly.

What are real-world examples of Weak Password Requirements?+

MITRE documents real CVEs mapped to CWE-521, including CVE-2020-4574. You can look up the full details of each CVE, including CVSS scores and remediation guidance, on our CVE Lookup tool.

What is the difference between a CWE and a CVE?+

A CWE (Common Weakness Enumeration) like CWE-521 describes a category of software weakness — the underlying flaw type. A CVE (Common Vulnerabilities and Exposures) identifies a specific, real-world vulnerability in a particular product. In short, a CWE is the kind of mistake, and a CVE is an instance of that mistake being found in software.

CWE-521: Weak Password Requirements

Technical Details

Applicable To

Security Consequences

Scope

Impact

Mitigation Strategies

Phase

Description

Phase

Description

Phase

Description

Phase

Description

Detection Methods

Code Examples & CVEs

Observed CVE Examples (1)

CWE Relationships

Parent Weaknesses

Source-backed guidance

Verify controls for CWE-521 with SSDF evidence

Address Weak Password Requirements during Architecture and Design

Triage CWE-521 against known exploitation evidence

Apply precise root-cause mapping to CWE-521

Validate CWE-521 with root-cause mapping checks

Frequently Asked Questions

Learn More