logo

Use of Password System for Primary Authentication

Draft Base
Structure: Simple
Description

This weakness occurs when an application relies solely on password-based authentication as its main security gate. This single-factor approach is inherently vulnerable to a range of attacks that can compromise user accounts.

Extended Description

Relying only on passwords for authentication creates a single point of failure in your security model. Passwords are frequently weak, reused across sites, or stolen through phishing, data breaches, or brute-force attacks. Without additional safeguards, an attacker who obtains a password gains full access to the associated account and its privileges. To mitigate this, you should implement defense-in-depth by adding secondary authentication factors (multi-factor authentication). Additionally, enforce strong password policies, use secure hashing algorithms (like Argon2 or bcrypt) for storage, and implement account lockouts or rate-limiting to thwart automated attacks. Treating passwords as the sole authentication method is a high-risk design choice in modern applications.
Common Consequences 1
Scope: Access Control

Impact: Bypass Protection MechanismGain Privileges or Assume Identity

A password authentication mechanism error will almost always result in attackers being authorized as valid users.
Potential Mitigations 6
Phase: Architecture and Design
In order to protect password systems from compromise, the following should be noted: - Passwords should be stored safely to prevent insider attack and to ensure that -- if a system is compromised -- the passwords are not retrievable. Due to password reuse, this information may be useful in the compromise of other systems these users work with. In order to protect these passwords, they should be stored encrypted, in a non-reversible state, such that the original text password cannot be extracted from the stored value. - Password aging should be strictly enforced to ensure that passwords do not remain unchanged for long periods of time. The longer a password remains in use, the higher the probability that it has been compromised. For this reason, passwords should require refreshing periodically, and users should be informed of the risk of passwords which remain in use for too long. - Password strength should be enforced intelligently. Rather than restrict passwords to specific content, or specific length, users should be encouraged to use upper and lower case letters, numbers, and symbols in their passwords. The system should also ensure that no passwords are derived from dictionary words.
Phase: Architecture and Design
Use a zero-knowledge password protocol, such as SRP.
Phase: Architecture and Design
Ensure that passwords are stored safely and are not reversible.
Phase: Architecture and Design
Implement password aging functionality that requires passwords be changed after a certain point.
Phase: Architecture and Design
Use a mechanism for determining the strength of a password and notify the user of weak password use.
Phase: Architecture and Design
Inform the user of why password protections are in place, how they work to protect data integrity, and why it is important to heed their warnings.
Demonstrative Examples 1

ID : DX-101

In both of these examples, a user is logged in if their given password matches a stored password:

Code Example:

Bad
C
c

//Login if hash matches stored hash* if (equal(ctext, secret_password())) { ``` login_user(); } }

Code Example:
Bad
Java
java


//Login if hash matches stored hash*
if (equal(digest,secret_password())) {
```
login_user();
}


This code relies exclusively on a password mechanism (Use of Password System for Primary Authentication) using only one factor of authentication (Use of Single-factor Authentication). If an attacker can steal or guess a user's password, they are given full access to their account. Note this code also uses SHA-1, which is a weak hash (Use of Weak Hash). It also does not use a salt (Use of a One-Way Hash without a Salt).
    
References 1
The CLASP Application Security Process
Secure Software, Inc.
2005
https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf(2024-11-17)
ID: REF-18
 
  
  
 
 
Likelihood of Exploit 
 
 
 
 High 
 
 
  
 
 
Applicable Platforms 
 
 
 
 
 
Languages:
 
 
 Not Language-Specific : Undetermined 
  
  
 
 
 
  
 
 
Modes of Introduction 
 
 
 
 
 
  Architecture and Design  
 
 
 
  
Related Attack Patterns 
        
 
 
Related Weaknesses 
 
 
 
 
  ChildOf:
 Weak Authentication (CWE-1390) 
  ChildOf:
 Reliance on a Single Factor in a Security Decision (CWE-654) 
  PeerOf:
 Use of Single-factor Authentication (CWE-308) 
 
 
 
 
Taxonomy Mapping 
  • CLASP
  • OWASP Top Ten 2004