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

From OWASP
Jump to: navigation, search
Line 1: Line 1:
 
{{Template:SecureSoftware}}
 
{{Template:SecureSoftware}}
 +
{{Template:Vulnerability}}
  
==Overview==
+
[[Category:FIXME|This is the text from the old template. This needs to be rewritten using the new template.]]
  
The use of a hard-coded password increases the possibility of password guessing tremendously.
+
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
  
==Consequences ==
+
[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]
  
* Authentication: If hard-coded passwords are used, it is almost certain that malicious users will gain access through the account in question.
+
[[ASDR Table of Contents]]
 +
__TOC__
  
==Exposure period ==
 
  
* Design: For both front-end to back-end connections and default account settings, alternate decisions must be made at design time.
+
==Description==
  
==Platform ==
+
The use of a hard-coded password increases the possibility of password guessing tremendously.
  
* Languages: All
+
'''Consequences'''
  
* Operating platforms: All
+
* Authentication: If hard-coded passwords are used, it is almost certain that malicious users will gain access through the account in question.
  
==Required resources ==
+
'''Exposure period'''
  
Knowledge of the product or access to code.
+
* Design: For both front-end to back-end connections and default account settings, alternate decisions must be made at design time.
  
==Severity ==
+
'''Platform'''
  
High
+
* Languages: All
 +
* Operating platforms: All
  
==Likelihood  of exploit ==
+
'''Required resources'''
  
Very high
+
Knowledge of the product or access to code.
  
==Avoidance and mitigation ==
+
'''Severity'''
  
* 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.
+
High
  
* 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.
+
'''Likelihood of exploit'''
  
==Discussion ==
+
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.
 
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.
Line 45: Line 47:
 
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.
 
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 ==
+
 
 +
==Risk Factors==
 +
 
 +
* 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
 +
 
 +
 
 +
==Examples==
 +
 
  
 
In C\C++:
 
In C\C++:
Line 77: Line 88:
 
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]]
  
  
[[Category:Vulnerability]]
+
==Related [[Vulnerabilities]]==
  
[[Category:Protocol Errors]]
+
* 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:OWASP_CLASP_Project]]
 
[[Category:OWASP_CLASP_Project]]

Revision as of 09:06, 3 October 2008

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

Last revision (mm/dd/yy): 10/3/2008

Vulnerabilities Table of Contents

ASDR 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