• Choose a category
• All
• Classic-Fiction

With the exceptions listed earlier while discussing the section, all sections in a configuration file can be encrypted both programmatically using the configuration API and in offline mode using a command-line tool. Let’s tackle this latter option first.

Using a Command-Line Tool

You use the newest version of a popular system tool: aspnet_regiis.exe. Here’s a sample usage of the utility to encrypt connection strings for the /MyApp application. Note that the section names are case-sensitive.

aspnet_regiis.exe -pe connectionStrings -app /MyApp

After running this command, the web.config looks different. The section now incorporates a child section, which is where the ciphered content has been stored. If you open the web.config file after encryption, you see something like the following:

configProtectionProvider="RsaProtectedConfigurationProvider">

...

cQyofWFQ ... =

To restore the web.config file to its original clear state, you use the –pd switch in lieu of –pe in the aforementioned command line. The nice part of the story is that this form of encryption is completely transparent to applications, which continue working as before.

Using a Programmatic Approach

To encrypt and decrypt sections programmatically, you use the ProtectSection and UnprotectSection methods defined on the SectionInformation object. Here’s how to proceed:

var name = "connectionStrings";

var path = "/myApp";

var provider = "RsaProtectedConfigurationProvider";

var config = WebConfigurationManager.OpenWebConfiguration(path);

var section = (ConnectionStringsSection) cfg.GetSection(name);

section.SectionInformation.ProtectSection(provider);

config.Save();

To unprotect, you change the call to ProtectSection with the following:

section.SectionInformation.UnprotectSection();

config.Save();

Note that to persist changes it is still essential to place a call to the Save method on the Configuration object.

Choosing the Encryption Provider

Any page that uses protected sections works like a champ as long as you run it inside the local Web server embedded in Visual Studio. You might get an RSA provider configuration error if you access the same page from within a canonical (and much more realistic) IIS virtual folder. What’s up with that?

The RSA-based provider—the default protection provider, if you use the command-line tool—needs a key container to work. A default key container is created upon installation and is named NetFrameWorkConfigurationKey. The aspnet_regiis.exe utility provides a lot of command-line switches for you to add, remove, and edit key containers. The essential point is that you have a key container created before you dump the RSA-protected configuration provider. The container must not only exist, but it also needs to be associated with the user account attempting to call it. The system account (running the local Web server) is listed with the container; the ASP.NET account on your Web server might not be. Note that granting access to the key container is necessary only if you use the RSA provider.

Assuming you run ASP.NET under the NETWORK SERVICE account (the default on Windows Server 2003 machines), you need the following code to add access to the container for the user:

aspnet_regiis.exe -pa "NetFrameworkConfigurationKey"

"NT AUTHORITY\NETWORK SERVICE"

It is important that you specify a complete account name, as in the preceding code. In IIS 7.5 where ApplicationPoolIdentity is used by default in lieu of NETWORK SERVICE, how would you identify the account exactly? Here’s how:

aspnet_regiis.exe -pa "NetFrameworkConfigurationKey"

"IIS APPPOOL\YourAppPool"

You use IIS APPPOOL followed by the name of the IIS application pool whose identity you want to retrieve.

Both the RSA and DPAPI providers are great options for encrypting sensitive data. The DPAPI provider dramatically