Overview of Protected Configuration
You can use protected configuration to encrypt sensitive information, including user names and passwords, database connection strings, and encryption keys, in a Web application configuration file such as the Web.config file. Encrypting configuration information can improve the security of your application by making it difficult for an attacker to gain access to the sensitive information even if the attacker gains access to your configuration file.
For example, an unencrypted configuration file might contain a section specifying connection strings used to connect to a database, as shown in the following example:
<configuration> <connectionStrings> <add name="SampleSqlServer" connectionString="Data Source=localhost;Integrated Security=SSPI;Initial Catalog=Northwind;" /> </connectionStrings> </configuration>
A configuration file that encrypts the connection string values using protected configuration does not show the connection strings in clear text, but instead stores them in encrypted form, as shown in the following example:
<configuration> <connectionStrings configProtectionProvider="RsaProtectedConfigurationProvider"> <EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element" xmlns="http://www.w3.org/2001/04/xmlenc#"> <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc" /> <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#"> <EncryptedKey xmlns="http://www.w3.org/2001/04/xmlenc#"> <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" /> <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#"> <KeyName>RSA Key</KeyName> </KeyInfo> <CipherData> <CipherValue>RXO/zmmy3sR0iOJoF4ooxkFxwelVYpT0riwP2mYpR3FU+r6BPfvsqb384pohivkyNY7Dm4lPgR2bE9F7k6TblLVJFvnQu7p7d/yjnhzgHwWKMqb0M0t0Y8DOwogkDDXFxs1UxIhtknc+2a7UGtGh6Di3N572qxdfmGfQc7ZbwNE= </CipherValue> </CipherData> </EncryptedKey> </KeyInfo> <CipherData> <CipherValue>KMNKBuV9nOid8pUvdNLY5I8R7BaEGncjkwYgshW8ClKjrXSM7zeIRmAy/cTaniu8Rfk92KVkEK83+UlQd+GQ6pycO3eM8DTM5kCyLcEiJa5XUAQv4KITBNBN6fBXsWrGuEyUDWZYm6Eijl8DqRDb11i+StkBLlHPyyhbnCAsXdz5CaqVuG0obEy2xmnGQ6G3Mzr74j4ifxnyvRq7levA2sBR4lhE5M80Cd5yKEJktcPWZYM99TmyO3KYjtmRW/Ws/XO3z9z1b1KohE5Ok/YX1YV0+Uk4/yuZo0Bjk+rErG505YMfRVtxSJ4ee418ZMfp4vOaqzKrSkHPie3zIR7SuVUeYPFZbcV65BKCUlT4EtPLgi8CHu8bMBQkdWxOnQEIBeY+TerAee/SiBCrA8M/n9bpLlRJkUb+URiGLoaj+XHym//fmCclAcveKlba6vKrcbqhEjsnY2F522yaTHcc1+wXUWqif7rSIPhc0+MT1hB1SZjd8dmPgtZUyzcL51DoChy+hZ4vLzE= </CipherValue> </CipherData> </EncryptedData> </connectionStrings>
When the page is requested, the .NET Framework decrypts the connection string information and makes it available to your application.
You cannot use protected configuration to encrypt the configProtectedData section of a configuration file. You also cannot use protected configuration to encrypt the configuration sections that do not employ a section handler or sections that are part of the managed cryptography configuration. The following is a list of configuration sections that cannot be encrypted using protected configuration: processModel, runtime, mscorlib, startup, system.runtime.remoting, configProtectedData, satelliteassemblies, cryptographySettings, cryptoNameMapping, and cryptoClasses. It is recommended that you use other means of encrypting sensitive information, such as the ASP.NET Set Registry console application (Aspnet_setreg.exe) tool, to protect sensitive information in these configuration sections. For information on the ASP.NET Set Registry console application (Aspnet_setreg.exe), see article Q329290, "How to use the ASP.NET utility to encrypt credentials and session state connection strings," in the Microsoft Knowledge Base at the Microsoft support Web site.
Encrypted configuration information is decrypted when loaded into the memory that is used by your application. If the memory for your application is compromised, the sensitive information from your protected configuration section might be compromised as well.
You manage protected configuration using the ASP.NET IIS Registration tool (Aspnet_regiis.exe) or the protected configuration classes in the System.Configuration namespace.
The Aspnet_regiis.exe tool (located in the %SystemRoot%\Microsoft.NET\Framework\versionNumber folder) includes options for encrypting and decrypting sections of a Web.config file, creating or deleting key containers, exporting and importing key container information, and managing access to a key container.
Encryption and decryption of the contents of a Web.config file is performed using a ProtectedConfigurationProvider class. The following list describes the protected configuration providers included in the .NET Framework:
DpapiProtectedConfigurationProvider. Uses the Windows Data Protection API (DPAPI) to encrypt and decrypt data.
RsaProtectedConfigurationProvider. Uses the RSA encryption algorithm to encrypt and decrypt data.
Both providers offer strong encryption of data; however, if you are planning to use the same encrypted configuration file on multiple servers, such as a Web farm, only the RsaProtectedConfigurationProvider enables you to export the encryption keys used to encrypt the data and import them on another server.
You can specify which ProtectedConfigurationProvider you want to use by configuring it in your application's Web.config file, or you can use one of the ProtectedConfigurationProvider instances configured in the Machine.config file. For more information, see Specifying a Protected Configuration Provider.
Once you have specified which provider to use, you can encrypt or decrypt the contents of the Web.config file for your application. For more information, see Encrypting and Decrypting Configuration Sections.
As a best practice when securing your Web applications, it is important that you always keep your application server up to date with the latest security patches for Microsoft Windows and Internet Information Services (IIS), as well as any security patches for Microsoft SQL Server or other membership data sources. For detailed information about best practices for writing secure code and securing applications, see the book "Writing Secure Code" by Michael Howard and David LeBlanc, and see the guidance provided on the Microsoft Patterns and Practices Web site.