ASP.NET applications can store user name and password pairs in <credentials> elements in the web.config file for an ASP.NET application, which supports plain text, MD5 and SHA1 password formats.

Passwords stored in plain text or using a weak encryption algorithm are accessible to anyone with the access to the application's configuration files. This may include the machine where the application is hosted or the source code repository where the application lives.

Example 1: The following web.config entry incorrectly stores its passwords in plain text.

<configuration>
  <system.web>
    <authentication>
      <forms protection="All">
	   <credentials passwordFormat="Clear">
   		<user name="user1" password="my_password"/>
		<user name="user2" password="my_password1"/>
        </credentials>
    	 </forms>
    </authentication>
  </system.web>
</configuration>

ASP.NET supports credential passwords stored in three formats, specified by the passwordFormat attribute of the configuration/system.web/authentication/forms/credentials element. The possible values for this attribute are:

Clear - indicates that the password is stored in plain text (least secure)
MD5 - indicates that the password's MD5 hash is stored
SHA1 - indicates that the password's SHA1 hash is stored (most secure)

While an MD5 hash is more secure than plain text, researchers have found brute-force attacks against the MD5 hashing algorithm. At this time, a SHA1 hash still provides reasonable protection against such attacks.

ASP.NET applications can store user name and password pairs in <credentials> elements in the web.config file for an ASP.NET application, which supports plain text, MD5 and SHA1 password formats.

Passwords stored in plain text or using a weak encryption algorithm are accessible to anyone with the access to the application's configuration files. This may include the machine where the application is hosted or the source code repository where the application lives.

Example 1: The following web.config entry incorrectly stores its passwords in plain text.

<configuration>
  <system.web>
    <authentication>
      <forms protection="All">
	   <credentials passwordFormat="Clear">
   		<user name="user1" password="my_password"/>
		<user name="user2" password="my_password1"/>
        </credentials>
    	 </forms>
    </authentication>
  </system.web>
</configuration>

ASP.NET supports credential passwords stored in three formats, specified by the passwordFormat attribute of the configuration/system.web/authentication/forms/credentials element. The possible values for this attribute are:

Clear - indicates that the password is stored in plain text (least secure)
MD5 - indicates that the password's MD5 hash is stored
SHA1 - indicates that the password's SHA1 hash is stored (most secure)

While an MD5 hash is more secure than plain text, researchers have found brute-force attacks against the MD5 hashing algorithm. At this time, a SHA1 hash still provides reasonable protection against such attacks.

This might enable the attacker to specify an empty minimum bits, which allows for both easier determination of the hashed values and a leak of information about how the program performs its cryptographic hashing. Weak Cryptographic Hash: User-Controlled Minimum bits issues occur when:

1. Data enters a program through an untrusted source.

2. The user-controlled data is included within the minimum bits, or used entirely as the minimum bits within a cryptographic hash function.


As with many software security vulnerabilities, Weak Cryptographic Hash: User-Controlled minimum bits is a means to an end, not an end in and of itself. At its root, the vulnerability is straightforward: an attacker passes malicious data to an application, and the data is then used as all or part of the minimum bits in a cryptographic hash function.

A user-controlled minimum bits can enable various attacks:

1. An attacker might use this vulnerability to specify an empty minimum bits for the data being hashed. An attacker can quickly hash the data being hashed using a number of different hashing algorithms to leak information about the hashing implementation used in your application. This could make "cracking" other data values easier by limiting the particular variant of hash used.
2. 2. If an attacker can manipulate other users' minimum bits, or trick other users into using an empty minimum bits, they can compute "rainbow tables" for the application and easily determine the hashed values.

Example 1: The following code uses a user-controlled minimum bits for password hashing:

    ...
    String minimumBits = prop.getProperty("minimumbits");
    Hashing.goodFastHash(minimumBits).hashString("foo", StandardCharsets.UTF_8);
    ...

The code in Example 1 runs successfully, but anyone who can get to this functionality can manipulate the minimum bits used to hash the password by modifying the property minimumBits. After the program ships, it can be difficult to undo an issue regarding user-controlled minimum bits, because you cannot know whether a password hash had its minimum bits set by a malicious user.

Weak Cryptographic Hash: User-Controlled Seed issues occur when:

1. Data enters a program through an untrusted source.

2. The user-controlled data is included within the seed, or used entirely as the seed within a cryptographic hash function.


As with many software security vulnerabilities, Weak Cryptographic Hash: User-Controlled seed is a means to an end, not an end in and of itself. At its root, the vulnerability is straightforward: an attacker passes malicious data to an application, and the data is then used as all or part of the seed in a cryptographic hash function.

A user-controlled seed can enable various attacks:

1. The attacker might use this vulnerability to specify an empty seed for the data being hashed. An attacker can quickly hash the data being hashed using a number of different hashing algorithms to leak information about the hashing implementation used within your application. This could make "cracking" other data values easier by limiting the particular variant of hash used.
2. If an attacker can manipulate other users' seeds, or trick other users into using an empty seed, then they could compute "rainbow tables" for the application and easily determine the hashed values.

Example 1: The following code uses a user-controlled seed for password hashing:

    ...
    String seed = prop.getProperty("seed");
    Hashing.murmur3_32_fixed(Integer.parseInt(seed)).hashString("foo", StandardCharsets.UTF_8);
    ...

The code in Example 1 runs successfully, but anyone who can get to this functionality can manipulate the seed used to hash the password by modifying the property seed. After the program ships, it can be difficult to undo an issue regarding user-controlled seeds, because you cannot know whether a password hash had its seed determined by a malicious user.

The OAuth protocol allows a user to leverage a third party application (a consumer) to access their resources on a provider application without sharing credentials from the provider to the consumer. Instead of traditional authentication tokens such as a username and password pair, the consumer uses a token and a shared secret to identify itself to the provider. Once the channel between the consumer and provider has been established, the individual users are authorized through that channel using an access key token and a shared secret provisioned by the provider.
The transmission and storage of these tokens and secrets should be performed as carefully as other credentials are in traditional web applications. In the absence of Secure Sockets Layer (SSL) or Transport Layer Security (TLS), these tokens and secrets are sent in plain text over HTTP and can be seen by anyone eavesdropping on the traffic.

Poorly written login forms could lead to the following vulnerabilities:

1. Theft of credential information
a. Login forms designed to use the GET HTTP method can reveal sensitive information to attackers in the query string.
b. Transmission of login information in cleartext leaves it vulnerable to information theft.
c. Serving login forms over non secure connection could allow an attacker to intercept and tamper the login form itself thus circumventing any protections offered by the original login form
d. Processing of unvalidated data in the page containing the login form could allow attackers to install malicious scripts and capture sensitive information
2. Authentication bypass
a. Failing to validate data submitted by the user via a login form could leave the application vulnerable to SQL Injection attacks allowing an attacker to completely bypass the authentication system
3. Session hijacking
a. In the absence of adequate protections against Cross-Site Request Forgery and Cross-Frame Scripting vulnerabilities, attackers can hijack legitimate user sessions.

If cookie-based sessions are used and SECRET_KEY is leaked, an attacker will be able to store arbitrary data in the session cookie which will be deserialized in the server leading to arbitrary code execution.

If cookie-based sessions are used, take extra care to make sure that the secret key is always kept completely secret, for any system which might be remotely accessible.

Example 1: The following view method allows an attacker to steal the SECRET_KEY if it is hardcoded in settings.py configuration file:

...
def some_view_method(request):
  url = request.GET['url']
  if "http://" in url:
    content = urllib.urlopen(url)
    return HttpResponse(content)
  ...

Example 1 method checks that the url parameter is a valid URL by checking that "http://" is present in the URL. A malicious attacker may send the following URL to leak the settings.py configuration file that may contain the SECRET_KEY:

file://proc/self/cwd/app/settings.py#http://

Note: "/proc/self/cwd" in UNIX systems points to the process working directory. This allow attackers to reference files without knowing the exact location.