CWE-645: Overly Restrictive Account Lockout Mechanism | Glexia
CWE-645 (Overly Restrictive Account Lockout Mechanism) weakness overview with consequences, detection methods, mitigations, related CVEs and MITRE ATT&CK context.
Glexia's Take · Automated analysis
CWE-645: Overly Restrictive Account Lockout Mechanism
Overly Restrictive Account Lockout Mechanism represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.
Executive Impact
- Availability: DoS: Resource Consumption (Other): Users could be locked out of accounts.
Developer Pattern
CWE-645 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-645, 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-645: Overly Restrictive Account Lockout Mechanism
The product contains an account lockout protection mechanism, but the mechanism is too restrictive and can be triggered too easily, which allows attackers to deny service to legitimate users by causing their accounts to be locked out.
Account lockout is a security feature often present in applications as a countermeasure to the brute force attack on the password based authentication mechanism of the system. After a certain number of failed login attempts, the users' account may be disabled for a certain period of time or until it is unlocked by an administrator. Other security events may also possibly trigger account lockout. However, an attacker may use this very security feature to deny service to legitimate system users. It is therefore important to ensure that the account lockout security mechanism is not overly restrictive.
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: Implement more intelligent password throttling mechanisms such as those which take IP address into account, in addition to the login name.
- Architecture and Design: Implement a lockout timeout that grows as the number of incorrect login attempts goes up, eventually resulting in a complete lockout.
- Architecture and Design: Consider alternatives to account lockout that would still be effective against password brute force attacks, such as presenting the user machine with a puzzle to solve (makes it do some computation).
Detection
- Code review
- SAST
- DAST
- Focused regression tests
Mappings
Related CVEs, CWEs, and ATT&CK context
Related CWEs
ATT&CK Relevance
ATT&CK relevance is shown only when reviewed or responsibly inferred.