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>

Revision as of 20:04, 20 February 2009

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

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."

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.