Top 10 Application Security Vulnerabilities in Web.config Files - Part Two

Hardcoded Credentials Used

Vulnerable configuration:

<configuration></configuration> 
<system.web>
<authentication mode="Forms">
  <forms>
<credentials></credentials>

</forms>
  </authentication> ...
</system.web>

Secure configuration:

<configuration></configuration> 
<system.web>
<authentication mode="Forms">
  <forms>

</forms>
  </authentication> ...
</system.web>

A fundamental difficulty of creating software is that the environment in which the application will be deployed is usually not the same environment in which it is created. In a production environment, the operating system may be different, the hardware on which the application runs may be more or less powerful, and test databases are replaced with live databases. This is an issue for creating Web-based applications that require authentication because developers and administrators often use test credentials to test the application security. This begs the question: Where do the test credentials come from?

For convenience, to avoid forcing developers from spending time on creating a credential store used solely for test purposes (and which would subsequently be discarded when the application went to production), Microsoft added a section to the Web.config file that you can use to quickly add test users to Web-based applications. For each test user, the developer adds an element to the configuration file with the desired user ID and password as shown below:

<authentication mode="Forms"> 
	<forms> 
	<credentials> 
		<user name="bob" password="bob"/> 
		<user name="jane" password="Elvis"/> 
	</credentials> 
	</forms>
</authentication> 

While undeniably convenient for development purposes, this was never intended for use in a production environment. Storing login credentials in plaintext in a configuration file is simply not secure. Anyone with read access to the Web.config file could access the authenticated Web application. It is possible to store the SHA-1 or MD5 hash of the password value, rather than storing the password in plaintext. This is somewhat better, but it is still not a secure solution. Using this method, the user name is still not encrypted. First, providing a known user name to a potential attacker makes it easier to perform a brute force attack against the system. Second, there are many reverse-lookup databases of SHA-1 and MD5 hash values available on the Internet. If the password is simple, such as a word found in a dictionary, then it is almost guaranteed to be found in one of these hash dictionaries.

The most secure way to store login credentials is to not store them in the configuration file. Remove the credentials element from your Web.config files in production applications.

You might also like...

Comments

About the author

Bryan Sullivan United States

Bryan Sullivan is a development manager at SPI Dynamics, a Web application security products company. Bryan manages the

  • www.spidynamics.com
  • Interested in writing for us? Find out more.

    Contribute

    Why not write for us? Or you could submit an event or a user group in your area. Alternatively just tell us what you think!

    Our tools

    We've got automatic conversion tools to convert C# to VB.NET, VB.NET to C#. Also you can compress javascript and compress css and generate sql connection strings.

    “In theory, theory and practice are the same. In practice, they're not.”