Difference between revisions of "Hard-Coded Password"

From OWASP
Jump to: navigation, search
 
(5 intermediate revisions by one user not shown)
Line 1: Line 1:
{{Template:Vulnerability}}
+
{{Template:Stub}} {{Template:Vulnerability}}  
  
{{Template:Stub}}
+
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
  
[[Category:FIXME|This is the text from the old template. This needs to be rewritten using the new template.]]
+
[[ASDR TOC Vulnerabilities|Vulnerabilities Table of Contents]]  
  
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
+
== Description ==
  
[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]
+
Hardcoded passwords may compromise system security in a way that cannot be easily remedied.
  
[[ASDR Table of Contents]]
+
It is never a good idea to hardcode a password. Not only does hardcoding a password allow all of the project's developers to view the password, it also makes fixing the problem extremely difficult. Once the code is in production, the password cannot be changed without patching the software. If the account protected by the password is compromised, the owners of the system will be forced to choose between security and availability.
__TOC__
+
  
[[Category:FIXME|Stub article, needs review]]
+
== Risk Factors ==
==Description==
+
  
A hard-coded password vulnerability occurs when usernames and passwords are included in HTML comments.  Because HTML comments are not displayed, it was often the mentality that normal users would not see them.  It can also occur when a specific username (usually unique) does not require a password.
+
TBD
  
==Risk Factors==
+
== Examples ==
  
TBD
+
This example shows how usernames and passwords can be included within HTML comments:
 +
<pre>&lt;form name="login" action="login.php" method="post" onSubmit="return email_Submit();"&gt;
 +
    &lt;b&gt;Log in Address: &lt;/b&gt;
 +
    &lt;input type="text" name="email" size="29" value=""&gt;
 +
    &lt;b&gt;Password: &lt;/b&gt;
 +
    &lt;input type="password" name="password" size="29" value=""&gt;
  
==Examples==
+
&lt;!-- Debugging credentials: wiki@owasp.org:abc123 --&gt;
  
This example shows how usernames and passwords can be included within HTML comments:
+
&lt;/form&gt;</pre>
 +
<br>
 +
The following code uses a hardcoded password to connect to a database: <br>
 +
<pre>
 +
...
 +
DriverManager.getConnection(url, "scott", "tiger");
 +
...
 +
</pre>
 +
<br>
 +
This code will run successfully, but anyone who has access to it will have access to the password. Once the program has shipped, there is no going back from the database user "scott" with a password of "tiger" unless the program is patched. A devious employee with access to this information can use it to break into the system. Even worse, if attackers have access to the bytecode for application, they can use the javap -c command to access the disassembled code, which will contain the values of the passwords used. The result of this operation might look something like the following for the example above:
  
<pre><form name="login" action="login.php" method="post" onSubmit="return email_Submit();">
+
<pre>
    <b>Log in Address: </b>
+
javap -c ConnMngr.class
    <input type="text" name="email" size="29" value="">
+
    <b>Password: </b>
+
22: ldc  #36; //String jdbc:mysql://ixne.com/rxsql
    <input type="password" name="password" size="29" value="">
+
24: ldc  #38; //String scott
 +
26: ldc  #17; //String tiger
  
<!-- Debugging credentials: wiki@owasp.org:abc123 -->
+
</pre>
 +
<br>
  
</form></pre>
+
== Related [[Attacks]] ==
  
==Related [[Attacks]]==
+
*[[Attack 1]]
 +
*[[Attack 2]]
  
* [[Attack 1]]
+
<br>
* [[Attack 2]]
+
  
 +
== Related [[Vulnerabilities]] ==
  
==Related [[Vulnerabilities]]==
+
== Related [[Controls]] ==
  
* [[Information Leak (information disclosure)]]
+
*[[:Category:Authentication]]
* [[Infoleak Using Debug Information]]
+
  
 +
== Related [[Technical Impacts]] ==
  
==Related [[Controls]]==
+
*[[Technical Impact 1]]
 +
*[[Technical Impact 2]]
  
* [[:Category:Authentication]]
+
<br>
  
==Related [[Technical Impacts]]==
+
== References ==
  
* [[Technical Impact 1]]
+
TBD __NOTOC__
* [[Technical Impact 2]]
+
  
 
+
[[Category:OWASP_ASDR_Project]] [[Category:Password_Management_Vulnerability]] [[Category:Authentication_Vulnerability]] [[Category:Sensitive_Data_Protection_Vulnerability]] [[Category:Vulnerability]]
==References==
+
 
+
TBD
+
__NOTOC__
+
 
+
 
+
[[Category:OWASP ASDR Project]]
+
[[Category:Password Management Vulnerability]]
+
[[Category:Authentication Vulnerability]]
+
[[Category:Sensitive Data Protection Vulnerability]]
+

Latest revision as of 11:39, 28 June 2011

This article is a stub. You can help OWASP by expanding it or discussing it on its Talk page.
This is a Vulnerability. To view all vulnerabilities, please see the Vulnerability Category page.


Last revision (mm/dd/yy): 06/28/2011

Vulnerabilities Table of Contents

Description

Hardcoded passwords may compromise system security in a way that cannot be easily remedied.

It is never a good idea to hardcode a password. Not only does hardcoding a password allow all of the project's developers to view the password, it also makes fixing the problem extremely difficult. Once the code is in production, the password cannot be changed without patching the software. If the account protected by the password is compromised, the owners of the system will be forced to choose between security and availability.

Risk Factors

TBD

Examples

This example shows how usernames and passwords can be included within HTML comments:

<form name="login" action="login.php" method="post" onSubmit="return email_Submit();">
    <b>Log in Address: </b>
    <input type="text" name="email" size="29" value="">
    <b>Password: </b>
    <input type="password" name="password" size="29" value="">

<!-- Debugging credentials: wiki@owasp.org:abc123 -->

</form>


The following code uses a hardcoded password to connect to a database:

	...
	DriverManager.getConnection(url, "scott", "tiger");
	...


This code will run successfully, but anyone who has access to it will have access to the password. Once the program has shipped, there is no going back from the database user "scott" with a password of "tiger" unless the program is patched. A devious employee with access to this information can use it to break into the system. Even worse, if attackers have access to the bytecode for application, they can use the javap -c command to access the disassembled code, which will contain the values of the passwords used. The result of this operation might look something like the following for the example above:

	javap -c ConnMngr.class
	
	22: ldc   #36; //String jdbc:mysql://ixne.com/rxsql
	24: ldc   #38; //String scott
	26: ldc   #17; //String tiger


Related Attacks


Related Vulnerabilities

Related Controls

Related Technical Impacts


References

TBD