Use of hard-coded password - Revision history

Jmanico at 09:52, 29 June 2016

2016-06-29T09:52:10Z

Seccoale: /* Examples */

2015-03-18T16:10:11Z

‎Examples

Jmanico at 19:06, 5 April 2014

2014-04-05T19:06:46Z

KirstenS at 02:04, 21 February 2009

2009-02-21T02:04:16Z

KirstenS at 14:24, 19 February 2009

2009-02-19T14:24:12Z

KirstenS at 14:31, 9 November 2008

2008-11-09T14:31:41Z

KirstenS at 14:06, 3 October 2008

2008-10-03T14:06:54Z

Pravir Chandra at 04:05, 28 May 2006

2006-05-28T04:05:39Z

Deleted user at 18:38, 16 May 2006

2006-05-16T18:38:13Z

Deleted user at 16:39, 16 April 2006

2006-04-16T16:39:18Z

@@ Line 56: / Line 56: @@
+   }
-   printf("Entering Diagnostic Mode�\n");
+   printf("Entering Diagnostic Mode\n");
    return 1;
+}
@@ Line 87: / Line 87: @@
 [[Category:Vulnerability]]

@@ Line 53: / Line 53: @@
    if (strcmp(password, "Mew!")) {
      printf("Incorrect Password!\n");
-     return(0)
+     return 0;
+   }
    printf("Entering Diagnostic Mode�\n");
-   return(1);
+   return 1;
+}
 </pre>
@@ Line 66: / Line 66: @@
 int VerifyAdmin(String password) {
-   if (passwd.Eqauls("Mew!")) {
+   if (password.equals("Mew!")) {
-     return(0)
+     return 0;
+   }
 //Diagnostic Mode
-   return(1);
+   return 1;
+}
 </pre>

@@ Line 1: / Line 1: @@
 Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
 ==Description==
@@ Line 80: / Line 75: @@
 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 [[Vulnerabilities]]==
@@ Line 92: / Line 80: @@
 * Use of hard-coded cryptographic key
 * Storing passwords in a recoverable format
 ==Related [[Controls]]==
@@ Line 102: / Line 86: @@
 * 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.
 [[Category:Vulnerability]]
 [[Category:Protocol Errors]]

@@ Line 1: / Line 1: @@
 {{Template:Vulnerability}}
 {{Template:SecureSoftware}}
 Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
 ==Description==

@@ Line 1: / Line 1: @@
 {{Template:Vulnerability}}
 {{Template:SecureSoftware}}
+<br>
 [[ASDR Table of Contents]]
 Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
 ==Description==
 The use of a hard-coded password increases the possibility of password guessing tremendously.

@@ Line 1: / Line 1: @@
 {{Template:SecureSoftware}}
-==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.
-==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
+'''Required resources'''
 Knowledge of the product or access to code.
-==Severity ==
+'''Severity'''
 High
-==Likelihood   of exploit ==
+'''Likelihood of exploit'''
 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.
-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==
-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==
 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."
-*	Use of hard-coded cryptographic key
+==Related [[Attacks]]==
-*	Storing passwords in a recoverable format
+==Related [[Vulnerabilities]]==
 [[Category:Vulnerability]]
 [[Category:Protocol Errors]]
 [[Category:OWASP_CLASP_Project]]

← Older revision		Revision as of 04:05, 28 May 2006
Line 83:		Line 83:
	* Storing passwords in a recoverable format		* Storing passwords in a recoverable format

−	~~==Categories ==~~

	[[Category:Vulnerability]]		[[Category:Vulnerability]]

← Older revision		Revision as of 18:38, 16 May 2006
Line 1:		Line 1:
−
	{{Template:SecureSoftware}}		{{Template:SecureSoftware}}

Line 89:		Line 88:

	[[Category:Protocol Errors]]		[[Category:Protocol Errors]]
		+
		+	[[Category:OWASP_CLASP_Project]]