Encrypting and Decrypting Configuration Information in ASP.NET Web.config - C# codes

Top

Introduction
When creating ASP.NET applications, developers commonly store sensitive configuration information in the Web.config file. The cannonical example is database connection strings, but other sensitive information included in the Web.config file can include SMTP server connection information and user credentials, among others. While ASP.NET is configured, by default, to reject all HTTP requests to resources with the .config extension, the sensitive information in Web.config can be compromised if a hacker obtains access to your Web server's file system. For example, perhaps you forgot to disallow anonymous FTP access to your website, thereby allowing a hacker to simply FTP in and download your Web.config file.

Fortunately ASP.NET 2.0 helps mitigate this problem by allowing selective portions of the Web.config file to be encrypted, such as the <connectionStrings> section and <appSettings> section , or some custom config section used by your application.

Configuration sections can be easily encrypted using:

  1. Program code
  2. aspnet_regiis.exe, a command-line program.

Once encrypted, the Web.config settings are safe from prying eyes. Furthermore, when retrieving encrypted congifuration settings programmatically in your ASP.NET pages, ASP.NET will automatically decrypt the encrypted sections its reading. In short, once the configuration information in encrypted, you don't need to write any further code or take any further action to use that encrypted data in your application.

In this article we'll see how to programmatically encrypt and decrypt portions of the configuration settings and look at using the aspnet_regiis.exe command-line program. We'll then evaluate the encryption options ASP.NET offers.

Encryption Options
Protecting configuration sections in ASP.NET uses the provider model, which allows for any implementation to be seamlessly plugged into the API. The .NET Framework ships with two built-in providers for protecting configuration sections:

  • The Windows Data Protection API (DPAPI) Provider (DataProtectionConfigurationProvider) - this provider uses the built-in cryptography capabilities of Windows to encrypt and decrypt the configuration sections. By default this provider uses the machine's key. You can also use user keys, but that requires a bit more customization. Since the keys are machine- or user- specific, the DPAPI provider does not work in settings where you wan to deploy the same encrypted configuration file to multiple servers.
  • RSA Protected Configuration Provider (RSAProtectedConfigurationProvider) - uses RSA public key encryption to encrypt/decrypt the configuration sections. With this provider you need to create key containers that hold the public and private keys used for encrypting and decrypting the configuration information. You can use RSA in a multi-server scenario by creating exportable key containers.

You can also create your own protected settings providers, if needed but we won't be discussing that here.

In this article we'll only explore using the DPAPI provider. This is, by far, the simplest approach since it doesn't require creating any keys or key containers, or ensuring access and permission rights to user-level keys. Of course, it has the downside that an encrypted configuration file can only be used on the web server that performed the encryption in the first place; furthermore, using the machine key would allow the encrypted text to be decrytable by any website on the web server.

 
1) Programmatically Encrypting Configuration Sections
The System.Configuration.SectionInformation class abstractly represents a configuration section. To encrypt a configuration section simply use the SectionInformation class'sProtectSection(<i>provider</i>) method, passing in the name of the provider you want to use to perform the encryption. To access a particular configuration section in your application'sWeb.config file, use the WebConfigurationManager class (in the System.Web.Configuration namespace) to reference your Web.config file, and then use its GetSection(<i>sectionName</i>) method to return a ConfigurationSection instance. Finally, you can get to a SectionInformation object via the ConfigurationSection instance's SectionInformation property.

This jumble of words should be made clearer by a simple code example (which I'm taking directly from David Hayden's blog entry Encrypt Connection Strings AppSettings and Web.Config in ASP.NET 2.0 - Security Best Practices:
private void ProtectSection(string sectionName, string provider)
{
Configuration config = WebConfigurationManager.OpenWebConfiguration(Request.ApplicationPath);

ConfigurationSection section = config.GetSection(sectionName);

if (section != null && !section.SectionInformation.IsProtected)
{
section.SectionInformation.ProtectSection(provider);
config.Save();
}
}

private void UnProtectSection(string sectionName)
{
Configuration config = WebConfigurationManager.OpenWebConfiguration(Request.ApplicationPath);

ConfigurationSection section = config.GetSection(sectionName);

if (section != null && section.SectionInformation.IsProtected)
{
section.SectionInformation.UnprotectSection();
config.Save();
}
}

This method David has created - ProtectSection(<i>sectionName</i>, <i>provider</i>) - can be called from an ASP.NET page, passing in a section name (like connectionStrings) and a provider (likeDataProtectionConfigurationProvider), and it opens the Web.config file, references the section, invokes the ProtectSection(<i>provider</i>) method of the SectionInformation object, and saves the configuration changes.
The UnProtectSection(<i>provider</i>) method decrypts a particular configuration section. Here only the section to decrypt needs to be passed in - we don't need to bother with the provider because that information is stored in the mark up accompanying the encrypted section (i.e., in the above example, the <connectionStrings> section, after being encrypted, included the provider: <connectionStrings <i>configProtectionProvider="DataProtectionConfigurationProvider"</i>>).

This method can be instantiated in the Page_load method of your class as below.

And can be Unprotected using the below code as well.

 
2) Using the aspnet_regiis.exe Command-Line Tool
You can also encrypt and decrypt sections in the Web.config file using the aspnet_regiis.exe command-line tool, which can be found in the %WINDOWSDIR%Microsoft.NetFramework<i>version </i>directory. To encrypt a section of the Web.config using the DPAPI machine key with this command-line tool, use:
-- Generic form for encrypting the Web.config file for a particular website...

  1. aspnet_regiis.exe -pef <i>section</i> <i>physical_directory</i> –prov <i>provider</i>
  2. -- or --
  3. aspnet_regiis.exe -pe <i>section</i> -app <i>virtual_directory</i> –prov <i>provider</i>

-- Concrete example of encrypting the Web.config file for a particular website...
aspnet_regiis.exe -pef "connectionStrings" "C:InetpubwwwrootMySite" –prov "DataProtectionConfigurationProvider"
-- or --
aspnet_regiis.exe -pe "connectionStrings" -app "/MySite" –prov "DataProtectionConfigurationProvider"-- Generic form for decrypting the Web.config file for a particular website...
aspnet_regiis.exe -pdf section physical_directory
-- or --
aspnet_regiis.exe -pd section -app virtual_directory
-- Concrete example of decrypting the Web.config file for a particular website...
aspnet_regiis.exe -pdf "connectionStrings" "C:InetpubwwwrootMySite"
-- or --
aspnet_regiis.exe -pd "connectionStrings" -app "/MySite"
 

You can also specify that aspnet_regiis.exe should perform encryption/decryption on the machine.config file instead. See the technical documentation for the ASP.NET IIS Registration Tool (Aspnet_regiis.exe) for more information on the available command-line switches.

Comments

Your are some sort of ideal internet marketer. The internet site launching rate will be incredible. It sort of feels that you are accomplishing any unique secret. Moreover, This articles will be must-see. you have carried out an excellent activity in this issue!

Share this page...

Twitter icon
Facebook icon
Google icon
StumbleUpon icon
Del.icio.us icon
Digg icon
LinkedIn icon
MySpace icon
Newsvine icon
Pinterest icon
Reddit icon
Technorati icon
Yahoo! icon
e-mail icon