logo

Empty Password in Configuration File

Incomplete Variant
Structure: Simple
Description

Using an empty string as a password is insecure.

Common Consequences 1
Scope: Access Control

Impact: Gain Privileges or Assume Identity
Potential Mitigations 1
Phase: System Configuration
Passwords should be at least eight characters long -- the longer the better. Avoid passwords that are in any way similar to other passwords you have. Avoid using words that may be found in a dictionary, names book, on a map, etc. Consider incorporating numbers and/or punctuation into your password. If you do use common words, consider replacing letters in that word with numbers and punctuation. However, do not use "similar-looking" punctuation. For example, it is not a good idea to change cat to c@t, ca+, (@+, or anything similar. Finally, it is never appropriate to use an empty string as a password.
Demonstrative Examples 1
The following examples show a portion of properties and configuration files for Java and ASP.NET applications. The files include username and password information but the password is provided as an empty string.
This Java example shows a properties file with an empty password string.

Code Example:

Bad
Java


Java Web App ResourceBundle properties file*


java
The following example shows a portion of a configuration file for an ASP.Net application. This configuration file includes username and password information for a connection to a database and the password is provided as an empty string.
Code Example:
Bad
ASP.NET
asp.net
An empty string should never be used as a password as this can allow unauthorized access to the application. Username and password information should not be included in a configuration file or a properties file in clear text. If possible, encrypt this information and avoid Password in Configuration File and ASP.NET Misconfiguration: Password in Configuration File.
  
Observed Examples 1
CVE-2022-26117Network access control (NAC) product has a configuration file with an empty password
  
References 2
Seven Pernicious Kingdoms: A Taxonomy of Software Security Errors
Katrina Tsipenyuk, Brian Chess, and Gary McGraw
NIST Workshop on Software Security Assurance Tools Techniques and Metrics • NIST
07-11-2005
https://samate.nist.gov/SSATTM_Content/papers/Seven%20Pernicious%20Kingdoms%20-%20Taxonomy%20of%20Sw%20Security%20Errors%20-%20Tsipenyuk%20-%20Chess%20-%20McGraw.pdf
ID: REF-6
Building Secure Software: How to Avoid Security Problems the Right Way
John Viega and Gary McGraw
Addison-Wesley
2002
ID: REF-207
 
  
  
 
 
Likelihood of Exploit 
 
 
 
 High 
 
 
  
 
 
Applicable Platforms 
 
 
 
 
 
Languages:
 
 
 Not Language-Specific : Undetermined 
  
  
 
 
 
  
 
 
Modes of Introduction 
 
 
 
 
 
  Architecture and Design  
 
  Implementation  
 
  Operation  
 
 
 
          
 
 
Related Weaknesses 
 
 
 
 
  ChildOf:
 Password in Configuration File (CWE-260) 
  ChildOf:
 Weak Password Requirements (CWE-521) 
 
 
 
 
Taxonomy Mapping 
  • 7 Pernicious Kingdoms