ASP.NET 2.0 introduces a system for protecting sensitive data stored in the application’s root configuration file—web.config. By running a system-provided command-line utility, you can use industry-standard XML encryption to protect specific sections of a configuration file that might contain sensitive data. XML encryption (see http://www.w3.org/TR/xmlenc-core) is a way to encrypt data and represent the result in XML.
Prior to ASP.NET Version 2.0, only a few specific configuration sections—the most critical ones from a security standpoint—could be protected through a machine-specific form of encryption. This approach has two major drawbacks. First, it is machine-specific because of the Windows Data Protection API (DPAPI). DPAPI is a cryptographic API that minimizes the burden of managing keys. Keys are autogenerated based on machine credentials and packed with the output. As obvious, that output can’t be ported to another machine. The second snag is that the output is in a binary format and stored in a registry key. Both facts lead straight to the conclusion that the xcopy deployment is inevitably broken.
In the .NET Framework 2.0, encryption of configuration sections is optional, and you can enable it for any configuration sections you wish by referencing the name of the section in the <protectedData> section of the web.config file. The following example shows how to protect the connectionStrings section.
<protectedData><br> <protectedDataSections><br> <add name="connectionStrings" <br> provider="RSAProtectedConfigurationProvider" /><br> </protectedDataSections><br></protectedData>
You can specify the type of encryption you want by selecting the appropriate provider from the list of available encryption providers. The .NET Framework 2.0 comes with two predefined providers. One is the DPAPIProtectedConfigurationProvider, which uses DPAPI to encrypt and decrypt data. The other is RSAProtectedConfigurationProvider. It is the default provider and uses the RSA encryption algorithm to encrypt and decrypt data.
Protection can be applied to all sections with very few exceptions. Let’s see how to encrypt connection strings stored into the web.config file. You can use the newest version of a popular system tool—aspnet_regiis.exe. The following command shows how to protect the connectionStrings section in the web.config file of the MyApp application.
aspnet_regiis.exe –pe connectionStrings –app /MyApp
Note the section names are case-sensitive. That connection strings are stored in a protected area is completely transparent to applications which continue working as before. If you open up the web.config file after encryption, you see something like the following:
<configuration><br> <protectedData><br> <protectedDataSections><br> <add name="connectionStrings" <br> provider="RSAProtectedConfigurationProvider" /><br> </protectedDataSections><br> </protectedData><br> <connectionStrings><br> <EncryptedData …><br> :<br> <CipherData><br> <CipherValue>cQyofWFQ… =</CipherValue><br> </CipherData><br> </EncryptedData><br> </connectionStrings><br></configuration>
To restore the web.config to its original clear state, you use the –pd switch in lieu of the –pe in the aforementioned command line.
The RSA provider does make use of keys. Where do keys used to protect data come from? Being able to control the keys is important in a web-farm scenario where the same encrypted web.config file will be deployed to several servers. In this case, the same key must also be deployed to all servers.
To accomplish this, you create a key container for the application, export it to an XML file, and import it on each server that will need to decrypt the encrypted web.config file. To create a key container you do as follows:
aspnet_regiis.exe –pc YourContainerName –exp
Next, you export the key container to an XML file, as follows:
aspnet_regiis.exe –pi YourContainerName YourXmlFile.xml
You can choose between the RSA and DPAPI provider. Both provide strong cryptographic algorithms; only the first, though, is ideal in a web-farm scenario or in situations where you need to frequently install the application on various production servers.
Dino Esposito is Wintellect's ADO.NET and XML expert, and a trainer and consultant
based in Rome, Italy. Dino is a contributing editor to Windows Developer
Network and MSDN Magazine, and the author of several books for Microsoft
Press including Building Web Solutions with ASP.NET and ADO.NET
and Applied XML Programming for .NET. Contact Dino at [email protected].
