Click here to Skip to main content
65,938 articles
CodeProject is changing. Read more.
Articles
(untagged)

How to Encrypt Web.config Using aspnet_regiis.exe (Framework 4+) Focus on Web Farms

0.00/5 (No votes)
17 Feb 2015 32  
This article provides a basic reference on how basic protection can be achieved using the aspnet_regiis.exe tool, by default installed with .Net Framework, and also some basic considerations when you are working with IIS WebFarms.

Introduction

While web.config file is the preferred store to save basic configuration settings, normally you do not care about sensitive information being exposed on it. Settings such as database connection strings and third party service credentials are usually stored in plain text, exposing them to malicious users. This post provides a basic reference on how basic protection can be achieved using the aspnet_regiis.exe tool, by default installed with .Net Framework, and also some basic considerations when you are working with IIS WebFarms. I will show an example on how use the RSA provider, however there is also the DPAPI provider available which is not covered in this article.

Encryption Providers

What is an encryption provider ? Basically it is a library that gives you the ability to encrypt sensitive data whether coding or using declarative configuration. Each encryption provider has its own pros and cons.

The basic aspnet_regiis.exe’s provider used is RsaProtectedConfigurationProvider, which use the RSA encryption algorithm. (more info (http://en.wikipedia.org/wiki/RSA_%28cryptosystem%29)

Also the DPAPI provider is available, it is installed by default as an operating system built-in component. (more info http://en.wikipedia.org/wiki/Data_Protection_API)

 Using RSA or DPAPI

-prov “RsaProtectedConfigurationProvider”

This method depends on private keys that can be shared among several machines, this makes it the right solution when working with several environments, such as development, testing and production. Also if you have to deal with a web farm having several IIS server’s, probably being synchronized by a DFS (Distributed File System).

-prov “DataProtectionConfigurationProvider”

This method depends on the machine where you originally encrypted the data, for example if machine A encrypts “hello world”, only machine A has the right keys to decrypt it. This result in a non-suitable solution when working with web farms.

Now that you know what is the provider that fits into your environment lets do the job.

Do you remember where aspnet_regiis.exe is located ? sure: C:\Windows\Microsoft.NET\Framework\v4.0.30319

So lets open a command prompt such as “Developer Command Prompt for VS2013″, be sure to have administrative permission. On the server you can use cmd.exe.

aspnet_regiis.exe -pef command (Encryption)

This command encrypt a specific section in a specific hard drive location, so for example to encrypt “appSettings” section in site located at “C:\inetpub\wwwroot\app\WebConfigEncryption” run:

aspnet_regiis.exe -pef appSettings  C:\inetpub\wwwroot\app\WebConfigEncryption

To encrypt “connectionStrings” section run:

aspnet_regiis.exe -pef connectionStrings  C:\inetpub\wwwroot\app\WebConfigEncryption

Important!!! Section names are case sensitive and also be sure to specify the path without “”.

This is the resultant file with both sections encrypted:

As I said, the RSA provider by default relys on keys that can be shared among several machines, however this is not the default behavior so I can not share a file encrypted on machine A with the machine B. I will receive an error as follows:

In the same way, I can not decrypt any data on machine B:

In order to share encrypted files among several machines refer to the following section.

Steps Required to Work With WebFarms

While working with single machine environments would not be tricky, WebFarms may require a little more attention. If you had worked with DFS’s (Distribuited File Systems) where the app files are automatically replicated among several machines , including .config files, the basic solution will not be suitable.

Here is where Key Containers appear to save the day.

A key container can be expressed as an xml file with the required key that can be used to encrypt/decrypt the data in several servers. One key container can be used among several applications, however in order to improve the security of an application’s sensitive configuration you can use several key containers, by doing so one’s application key container could not be used to decrypt web.config files encrypted with another key container.

Step 1: Creating an RSA Container

Aspnet_regiis.exe -pc “myApp1SampleKeys” -exp

This command requires 3 arguments:

  1. -pc : I want to create an RSA public/private key container.
  2. “name” : the key container name used in the web.config file.
  3. -exp: allow the container to be exportable.

Step 2: Granting Access To An RSA Key Container

aspnet_regiis -pa “myApp1SampleKeys” “NT AUTHORITY\NETWORK SERVICE”

This command requires 3 arguments:

  1. -pa: I want to grant access to my key container.
  2. “name” : the key container’s name.
  3. “account”: account name being granted access. 

Step 3: Updating app’s web.config file to specify a customProvider

<configProtectedData>
<providers>
<add name="customProvider"
type="System.Configuration.RsaProtectedConfigurationProvider, System.Configuration, Version=2.0.0.0,
Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
keyContainerName="myApp1SampleKeys"
useMachineContainer="true" />
</providers>
</configProtectedData>

Be sure to check these two values:

  1. The provider name “customProvider”
  2. The KeyContainerName “myApp1SampleKeys”

Step 4: Encrypting appSection Using Our New CustomProvider

aspnet_regiis.exe -pef appSettings C:\inetpub\wwwroot\app\WebConfigEncryption -prov “customProvider”

This will be the result:

Step 5: Exporting the Key Container in Order to be Used in Other Machines

aspnet_regiis -px “myApp1SampleKeys” c:\myApp1SampleKeys.xml -pri

This command requires 4 arguments:

  1. -px: I want to export my key container.
  2. “name” : the key container’s name.
  3. “path”: the path where the xml file will be created.
  4. -pri: also include the private key.

Step 6: Importing the Key Container on Another Machine

aspnet_regiis -pi “myApp1SampleKeys” c:\myApp1SampleKeys.xml

This command requires 3 arguments:

  1. -pi: I want to import a key container.
  2. “name” : the key container’s name.
  3. “path”: the path where the xml file will be read.

Step 7: Granting Access to Our New RSA Key Container

aspnet_regiis -pa “myApp1SampleKeys” “NT AUTHORITY\NETWORK SERVICE”

Required in order to read the key container.

Step 8: Delete the Xml File From Your Server

Do not let an attacker find the XML with the keys.

aspnet_regiis.exe -pdf command (Decryption)

The last useful command is -pdf which allows us to decrypt any previously encrypted section.

aspnet_regiis.exe -pdf appSettings C:\inetpub\wwwroot\app\WebConfigEncryption

This command requires 3 arguments:

    1. -pdf: I want to decrypt a value.
    2. “name” : the key sections’s name having the encrypted value.
    3. path: the path of the web.config file.

Accesing Encrypted Values Within Source Code

Encrypted values can be read at runtime as if they were not encoded, keep in mind that while the application is running encrypted data could be read from memory so you probably would need to use an specialized string such as SecureString Class (https://msdn.microsoft.com/en-us/library/system.security.securestring%28v=vs.110%29.aspx).

Overall, keeping as secure as possible the settings contained in a web.config should be one of the main concerns in both release and configuration management policies.

History

2015/02/17 : First Publish

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here