Difference between revisions of "Use of hard-coded password"

From OWASP
Jump to: navigation, search
(5 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 
+
{{Template:Vulnerability}}
 
{{Template:SecureSoftware}}
 
{{Template:SecureSoftware}}
  
==Overview==
+
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
 +
 
 +
[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]
  
 +
==Description==
 
The use of a hard-coded password increases the possibility of password guessing tremendously.
 
The use of a hard-coded password increases the possibility of password guessing tremendously.
  
==Consequences ==
+
'''Consequences'''
  
* Authentication: If hard-coded passwords are used, it is almost certain that malicious users will gain access through the account in question.
+
* Authentication: If hard-coded passwords are used, it is almost certain that malicious users will gain access through the account in question.
  
==Exposure period ==
+
'''Exposure period'''
  
* Design: For both front-end to back-end connections and default account settings, alternate decisions must be made at design time.
+
* Design: For both front-end to back-end connections and default account settings, alternate decisions must be made at design time.
  
==Platform ==
+
'''Platform'''
  
* Languages: All
+
* Languages: All
 +
* Operating platforms: All
  
* Operating platforms: All
+
'''Required resources'''
 
+
==Required resources ==
+
  
 
Knowledge of the product or access to code.
 
Knowledge of the product or access to code.
  
==Severity ==
+
'''Severity'''
  
 
High
 
High
  
==Likelihood   of exploit ==
+
'''Likelihood of exploit'''
  
 
Very high
 
Very high
  
==Avoidance and mitigation ==
+
The use of a hard-coded password has many negative implications - the most significant of these being a failure of authentication measures under certain circumstances.
  
* Design (for default accounts): Rather than hard code a default username and password for first time logins, utilize a "first login" mode which requires the user to enter a unique strong password.
+
On many systems, a default administration account exists which is set to a simple default password which is hard-coded into the program or device. This hard-coded password is the same for each device or system of this type and often is not changed or disabled by end users. If a malicious user comes across a device of this kind, it is a simple matter of looking up the default password (which is freely available and public on the internet) and logging in with complete access.  
  
* Design (for front-end to back-end connections): Three solutions are possible, although none are complete. The first suggestion involves the use of generated passwords which are changed automatically and must be entered at given time intervals by a system administrator. These passwords will be held in memory and only be valid for the time intervals. Next, the passwords used should be limited at the back end to only performing actions valid to for the front end, as opposed to having full access. Finally, the messages sent should be tagged and checksummed with time sensitive values so as to prevent replay style attacks.
+
In systems which authenticate with a back-end service, hard-coded passwords within closed source or drop-in solution systems require that the back-end service use a password which can be easily discovered. Client-side systems with hard-coded passwords propose even more of a threat, since the extraction of a password from a binary is exceedingly simple.
  
==Discussion ==
 
  
The use of a hard-coded password has many negative implications - the most significant of these being a failure of authentication measures under certain circumstances.
+
==Risk Factors==
  
On many systems, a default administration account exists which is set to a simple default password which is hard-coded into the program or device. This hard-coded password is the same for each device or system of this type and often is not changed or disabled by end users. If a malicious user comes across a device of this kind, it is a simple matter of looking up the default password (which is freely available and public on the internet) and logging in with complete access.
+
* Talk about the [[OWASP Risk Rating Methodology|factors]] that make this vulnerability likely or unlikely to actually happen
 +
* Discuss the technical impact of a successful exploit of this vulnerability
 +
* Consider the likely [business impacts] of a successful attack
  
In systems which authenticate with a back-end service, hard-coded passwords within closed source or drop-in solution systems require that the back-end service use a password which can be easily discovered. Client-side systems with hard-coded passwords propose even more of a threat, since the extraction of a password from a binary is exceedingly simple.
 
  
==Examples ==
+
==Examples==
 +
 
  
 
In C\C++:
 
In C\C++:
Line 78: Line 81:
 
Every instance of this program can be placed into diagnostic mode with the same password. Even worse is the fact that if this program is distributed as a binary-only distribution, it is very difficult to change that password or disable this "functionality."
 
Every instance of this program can be placed into diagnostic mode with the same password. Even worse is the fact that if this program is distributed as a binary-only distribution, it is very difficult to change that password or disable this "functionality."
  
==Related problems ==
 
  
* Use of hard-coded cryptographic key
+
==Related [[Attacks]]==
  
* Storing passwords in a recoverable format
+
* [[Attack 1]]
 +
* [[Attack 2]]
  
==Categories ==
 
  
[[Category:Vulnerability]]
+
==Related [[Vulnerabilities]]==
  
 +
* Use of hard-coded cryptographic key
 +
* Storing passwords in a recoverable format
 +
 +
 +
 +
 +
 +
==Related [[Controls]]==
 +
 +
* Design (for default accounts): Rather than hard code a default username and password for first time logins, utilize a "first login" mode which requires the user to enter a unique strong password.
 +
* Design (for front-end to back-end connections): Three solutions are possible, although none are complete. The first suggestion involves the use of generated passwords which are changed automatically and must be entered at given time intervals by a system administrator. These passwords will be held in memory and only be valid for the time intervals. Next, the passwords used should be limited at the back end to only performing actions valid to for the front end, as opposed to having full access. Finally, the messages sent should be tagged and checksummed with time sensitive values so as to prevent replay style attacks.
 +
 +
 +
==Related [[Technical Impacts]]==
 +
 +
* [[Technical Impact 1]]
 +
* [[Technical Impact 2]]
 +
 +
 +
==References==
 +
 +
TBD
 +
[[Category:FIXME|add links
 +
 +
In addition, one should classify vulnerability based on the following subcategories: Ex:<nowiki>[[Category:Error Handling Vulnerability]]</nowiki>
 +
 +
Availability Vulnerability
 +
 +
Authorization Vulnerability
 +
 +
Authentication Vulnerability
 +
 +
Concurrency Vulnerability
 +
 +
Configuration Vulnerability
 +
 +
Cryptographic Vulnerability
 +
 +
Encoding Vulnerability
 +
 +
Error Handling Vulnerability
 +
 +
Input Validation Vulnerability
 +
 +
Logging and Auditing Vulnerability
 +
 +
Session Management Vulnerability]]
 +
 +
__NOTOC__
 +
 +
 +
[[Category:OWASP ASDR Project]]
 +
[[Category:Vulnerability]]
 
[[Category:Protocol Errors]]
 
[[Category:Protocol Errors]]
 +
[[Category:OWASP_CLASP_Project]]

Revision as of 21:04, 20 February 2009

This is a Vulnerability. To view all vulnerabilities, please see the Vulnerability Category page.



Last revision (mm/dd/yy): 02/20/2009

Vulnerabilities Table of Contents

Description

The use of a hard-coded password increases the possibility of password guessing tremendously.

Consequences

  • Authentication: If hard-coded passwords are used, it is almost certain that malicious users will gain access through the account in question.

Exposure period

  • Design: For both front-end to back-end connections and default account settings, alternate decisions must be made at design time.

Platform

  • Languages: All
  • Operating platforms: All

Required resources

Knowledge of the product or access to code.

Severity

High

Likelihood of exploit

Very high

The use of a hard-coded password has many negative implications - the most significant of these being a failure of authentication measures under certain circumstances.

On many systems, a default administration account exists which is set to a simple default password which is hard-coded into the program or device. This hard-coded password is the same for each device or system of this type and often is not changed or disabled by end users. If a malicious user comes across a device of this kind, it is a simple matter of looking up the default password (which is freely available and public on the internet) and logging in with complete access.

In systems which authenticate with a back-end service, hard-coded passwords within closed source or drop-in solution systems require that the back-end service use a password which can be easily discovered. Client-side systems with hard-coded passwords propose even more of a threat, since the extraction of a password from a binary is exceedingly simple.


Risk Factors

  • Talk about the factors that make this vulnerability likely or unlikely to actually happen
  • Discuss the technical impact of a successful exploit of this vulnerability
  • Consider the likely [business impacts] of a successful attack


Examples

In C\C++:

int VerifyAdmin(char *password) {
 
  if (strcmp(password, "Mew!")) {
    printf("Incorrect Password!\n");
    return(0)
  }

  printf("Entering Diagnostic Mode�\n");
  return(1);
}

In Java:

int VerifyAdmin(String password) {
  
  if (passwd.Eqauls("Mew!")) {
    return(0)
  }
//Diagnostic Mode
  return(1);
}

Every instance of this program can be placed into diagnostic mode with the same password. Even worse is the fact that if this program is distributed as a binary-only distribution, it is very difficult to change that password or disable this "functionality."


Related Attacks


Related Vulnerabilities

  • Use of hard-coded cryptographic key
  • Storing passwords in a recoverable format



Related Controls

  • Design (for default accounts): Rather than hard code a default username and password for first time logins, utilize a "first login" mode which requires the user to enter a unique strong password.
  • Design (for front-end to back-end connections): Three solutions are possible, although none are complete. The first suggestion involves the use of generated passwords which are changed automatically and must be entered at given time intervals by a system administrator. These passwords will be held in memory and only be valid for the time intervals. Next, the passwords used should be limited at the back end to only performing actions valid to for the front end, as opposed to having full access. Finally, the messages sent should be tagged and checksummed with time sensitive values so as to prevent replay style attacks.


Related Technical Impacts


References

TBD