CWE-640: Weak Password Recovery Mechanism for Forgotten… | Glexia
CWE-640 (Weak Password Recovery Mechanism for Forgotten Password) weakness overview with consequences, detection methods, mitigations, related CVEs and MITRE…
Glexia's Take · Automated analysis
CWE-640: Weak Password Recovery Mechanism for Forgotten Password
Weak Password Recovery Mechanism for Forgotten Password represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.
Executive Impact
- Access Control: Gain Privileges or Assume Identity: An attacker could gain unauthorized access to the system by retrieving legitimate user's authentication credentials.
- Availability: DoS: Resource Consumption (Other): An attacker could deny service to legitimate system users by launching a brute force attack on the password recovery mechanism using user ids of legitimate users.
- Integrity,Other: Other: The system's security functionality is turned against the system by the attacker.
Developer Pattern
CWE-640 is the kind of defect developers can usually prevent with explicit validation, safer framework defaults, and tests that exercise hostile input or unsafe state transitions.
Automation confidence
high confidence from CWE-640, 4.20.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Official CWE Definition
CWE-640: Weak Password Recovery Mechanism for Forgotten Password
The product contains a mechanism for users to recover or change their passwords without knowing the original password, but the mechanism is weak.
Developer And Remediation Guidance
How teams prevent and detect this weakness
Causes
- A famous example of this type of weakness being exploited is the eBay attack. eBay always displays the user id of the highest bidder. In the final minutes of the auction, one of the bidders could try to log in as the highest bidder three times. After three incorrect log in attempts, eBay password throttling would kick in and lock out the highest bidder's account for some time. An attacker could then make their own bid and their victim would not have a chance to place the counter bid because they would be locked out. Thus an attacker could win the auction.
Remediation
- Architecture and Design: Make sure that all input supplied by the user to the password recovery mechanism is thoroughly filtered and validated.
- Architecture and Design: Do not use standard weak security questions and use several security questions.
- Architecture and Design: Make sure that there is throttling on the number of incorrect answers to a security question. Disable the password recovery functionality after a certain (small) number of incorrect guesses.
- Architecture and Design: Require that the user properly answers the security question prior to resetting their password and sending the new password to the e-mail address of record.
- Architecture and Design: Never allow the user to control what e-mail address the new password will be sent to in the password recovery mechanism.
- Architecture and Design: Assign a new temporary password rather than revealing the original password.
Detection
- Code review
- SAST
- DAST
- Focused regression tests
Mappings
Related CVEs, CWEs, and ATT&CK context
ATT&CK Relevance
ATT&CK relevance is shown only when reviewed or responsibly inferred.