No Sensitive Data in XML or Configuration Files

I know I mentioned this at the start of this chapter, but it's worth commenting on again. Storing data in configuration files, such as web.config, is fine so long as the data is not sensitive. However, passwords, keys, and database connection strings should be stored out of the sight of the attacker. Placing sensitive data in the registry is more secure than placing it in harm's way. Admittedly, this does violate the xcopy-deployment goal, but life's like that sometimes.

ASP.NET v1.1 supports optional Data Protection API encryption of secrets stored in a protected registry key. (Refer to Chapter 9, Protecting Secret Data, for information about DPAPI.) The configuration sections that can take advantage of this are <processModel>, <identity>, and <sessionState>. When using this feature, the configuration file points to the registry key and value that holds the secret data. ASP.NET provides a small command-line utility named aspnet_setreg to create the protected secrets. Here's an example configuration file that accesses the username and password used to start the ASP.NET worker process:

<system.web> <processModel enable="true" userName="registry:HKLM\Software\SomeKey,userName" password="registry:HKLM\Software\SomeKey,passWord" ... /> </system.web>

The secrets are protected by CryptProtectData using a machine-level encryption key. Although this does not mitigate all the threats associated with storing secrets anyone with physical access to the computer can potentially access the data it does considerably raise the bar over storing secrets in the configuration system itself.

This technique is not used to store arbitrary application data; it is only for usernames and passwords used for ASP.NET process identity and state service connection data.