Encrypt Connection Information

Configuration information for ASP.NET applications is commonly stored in an XML file named Web.config. Over the course of these tutorials we have updated the Web.config a handful of times. When creating the Northwind Typed DataSet in the first tutorial, for example, connection string information was automatically added to Web.config in the section. Later, in the Master Pages and Site Navigation tutorial, we manually updated Web.config, adding a element indicating that all of the ASP.NET pages in our project should use the DataWebControls Theme.

Since Web.config may contain sensitive data such as connection strings, it is important that the contents of Web.config be kept safe and hidden from unauthorized viewers. By default, any HTTP request to a file with the .config extension is handled by the ASP.NET engine, which returns the This type of page is not served message shown in Figure 1. This means that visitors cannot view your Web.config file s contents by simply entering https://www.YourServer.com/Web.config into their browser s Address bar.

Certain Web.config sections, however, contain sensitive information that may include connection strings, user names, passwords, server names, encryption keys, and so forth. This information is typically found in the following Web.config sections:

Protected Configuration Options

ASP.NET 2.0 includes a protected configuration system for encrypting and decrypting configuration information. This includes methods in the .NET Framework that can be used to programmatically encrypt or decrypt configuration information. The protected configuration system uses the provider model, which allows developers to choose what cryptographic implementation is used.

The .NET Framework ships with two protected configuration providers:

• RSAProtectedConfigurationProvider - uses the asymmetric RSA algorithm for encryption and decryption.
• DPAPIProtectedConfigurationProvider - uses the Windows Data Protection API (DPAPI) for encryption and decryption.

Since the protected configuration system implements the provider design pattern, it is possible to create your own protected configuration provider and plug it into your application. See Implementing a Protected Configuration Provider for more information on this process.

The RSA and DPAPI providers use keys for their encryption and decryption routines, and these keys can be stored at the machine- or user-level. Machine-level keys are ideal for scenarios where the web application runs on its own dedicated server or if there are multiple applications on a server that need to share encrypted information. User-level keys are a more secure option in shared hosting environments where other applications on the same server should not be able to decrypt your application s protected configuration sections.

In this tutorial our examples will use the DPAPI provider and machine-level keys. Specifically, we will look at encrypting the section in Web.config, although the protected configuration system can be used to encrypt most any Web.config section. For information on using user-level keys or using the RSA provider, consult the resources in the Further Readings section at the end of this tutorial.

Note: The RSAProtectedConfigurationProvider and DPAPIProtectedConfigurationProvider providers are registered in the machine.config file with the provider names RsaProtectedConfigurationProvider and DataProtectionConfigurationProvider, respectively. When encrypting or decrypting configuration information we will need to supply the appropriate provider name (RsaProtectedConfigurationProvider or DataProtectionConfigurationProvider) rather than the actual type name (RSAProtectedConfigurationProvider and DPAPIProtectedConfigurationProvider). You can find the machine.config file in the $WINDOWS$\Microsoft.NET\Framework\version\CONFIG folder.

--Microsoft