ASP.NET 2.0 Security Practices - Configuration

From Guidance Share

Jump to: navigation, search

Contents

How to encrypt sensitive data in Machine.config and Web.config

In ASP.NET 2.0, use the Aspnet_regiis.exe tool with the -pe (provider encryption) option to encrypt sections of the Machine.config and Web.config files.


To encrypt the connectionStrings section by using the DPAPI provider with the machine key store (the default configuration), run the following command from a command prompt:

aspnet_regiis -pe "connectionStrings" -app "/MachineDPAPI" -prov "DataProtectionConfigurationProvider"
  • -pe specifies the configuration section to encrypt.
  • -app specifies your Web application's virtual path. If your application is nested, you need to specify the nested path from the root directory, for example "/test/aspnet/MachineDPAPI"
  • -prov specifies the provider name.


The .NET Framework 2.0 SDK supports RSAProtectedConfigurationProvider and DPAPIProtectedConfigurationProvider protected configuration providers, which you use with the Aspnet_regiis.exe tool:

  • RSAProtectedConfigurationProvider. This is the default provider and uses the RSA public key encryption to encrypt and decrypt data. Use this provider to encrypt configuration files for use on multiple Web servers in a Web farm.
  • DPAPIProtectedConfigurationProvider. This provider uses the Windows Data Protection API (DPAPI) to encrypt and decrypt data. Use this provider to encrypt configuration files for use on a single Windows Server.


The following sections often contain sensitive information that you need to encrypt:

  • <appSettings>. Custom application settings.
  • <connectionStrings>. Connection strings.
  • <identity>. Web application identity. Can contain impersonation credentials.
  • <sessionState>. Contains connection string for out of process session provider.


You do not need any special steps for decryption, because the ASP.NET runtime takes care of this for you. You cannot use the Aspnet_regiis.exe tool and protected configuration to encrypt the following sections in Web.config and Machine.config:

<processModel>, <runtime>, <mscorlib>, <startup>, <system.runtime.remoting>, <configProtectedData>, <satelliteassemblies>, <cryptographySettings>, <cryptoNameMapping>, and <cryptoClasses>.

For these sections, use the Aspnet_setreg.exe tool. You must also use this tool with ASP.NET 1.1. For more information about AspNet-setreg.exe, see Microsoft Knowledge Base article 329290, How to use the ASP.NET utility to encrypt credentials and session state connection strings.


For more information on encrypting configuration sections, see How To: Encrypt Configuration Sections in ASP.NET 2.0 Using DPAPI and How To: Encrypt Configuration Sections in ASP.NET 2.0 Using RSA.

How to choose between machine and user key storage

The DPAPI and RSA protected configuration providers used to encrypt sensitive data in configuration files can use either machine stores or user stores for key storage. You can either store the key in the machine store and create an ACL for your specific application identity or store the key in a user store. In the latter case, you need to load the user account's profile to access the key.


Use machine-level key storage when:

  • Your application runs on its own dedicated server with no other applications.
  • You have multiple applications on the same server that run using the same identity and you want those applications to be able to share sensitive information and the same encryption key.


The DPAPI machine key is stored at the following location:

%windir%\system32\Microsoft\Protect\S-1-5-18


The RSA machine key is stored at the following location:

\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys


Use user-level key storage if:

You run your application in a shared hosting environment and you want to ensure that your application's sensitive data is not accessible to other applications on the server. In this scenario, each application should have a separate identity so that they all have their own individual and private key stores.


RSA user-level key containers are stored in the following folder:

\Documents and Settings\{UserName}\Application Data\Microsoft\Crypto\RSA


The DPAPI user key is stored in a folder at the following location:

\Documents and Settings\{UserName}\Application Data\Microsoft\Protect

How to use DPAPI with a user store to encrypt a connection string in Web.config

By default, the DataProtectionConfigurationProvider is configured to use DPAPI with the machine store. To use it with the user store, add a <configProtectedData> section to your Web.config file and set the useMachineProtection attribute to false as shown here. You must also specify a unique provider name.

<configProtectedData>
  <providers>
    <add useMachineProtection="false" keyEntropy="" 
     name="MyUserDataProtectionConfigurationProvider" 
     type="System.Configuration.DpapiProtectedConfigurationProvider, System.Configuration, 
     Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
  </providers>
</configProtectedData>


Then run the following command from a command prompt to encrypt the <connectionStrings> section:

aspnet_regiis –pe "connectionStrings" –app "/UserDPAPI" -prov "MyUserDataProtectionConfigurationProvider"


The <providers> configuration ensures that DPAPI is used with the user store. Make sure that your application is running with the same user identity as the account you used to encrypt the data. For more information, see How To: Encrypt Configuration Sections in ASP.NET 2.0 Using DPAPI.

How to use RSA with a user-level key container to encrypt a connection string in Web.config

The RSAProtectedConfigurationProvider is the default provider and is configured to use the machine-level key container. To use it with a user-level key container, add a <configProtectedData> section to your Web.config file and set the useMachineContainer attribute to false as shown here.

<configProtectedData>
  <providers>   
    <add keyContainerName="NetFrameworkConfigurationKey"
      useMachineContainer="false"
      description="Uses RsaCryptoServiceProvider to encrypt and decrypt"
      name="MyUserRSAProtectedConfigurationprovider" 
      type="System.Configuration.RsaProtectedConfigurationProvider,System.Configuration, 
      Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
    </providers>   
</configProtectedData>


Then run the following command from a command prompt to encrypt the <connectionStrings> section:

aspnet_regiis -pe "connectionStrings" -app "/UserRSA"–prov "MyUserRSAProtectedConfigurationProvider"


The <providers> configuration ensures that RSA is used with the user-level key container. Make sure that your application is running with the same user identity as the account you used to encrypt the data. For more information, see How To: Encrypt Configuration Sections in ASP.NET 2.0 Using RSA.

How to run an ASP.NET application with a particular identity

In IIS 6.0, use IIS Manager to create an application pool running as a specific identity. Use IIS Manager to assign your application to that application pool.


In IIS 5.0, you can configure the ASP.NET process identity by setting the userName and password attributes on the <processModel> element in Machine.config. If you do this, you should encrypt the credentials by using the Aspnet_setreg.exe utility.

How to create a service account for ASP.NET

To create a service account:

  1. Create a Windows account
  2. Run the following Aspnet_regiis.exe command to assign the relevant ASP.NET permissions to the account:
    aspnet_regiis.exe -ga machineName\userName
    On Windows 2003, running the Aspnet_regiis.exe -ga command will add the account to the IIS_WPG group. The IIS_WPG group provides the Log on as a batch job permission and ensures that the necessary file system permissions are granted.
  3. Use the Local Security Policy tool to grant the Windows account the Deny logon locally user right. This reduces the privileges of the account and prevents anyone logging onto Windows locally with the account.
  4. Use IIS Manager to create an application pool running under the new account's identity and assign the ASP.NET application to the pool.


For more information, see How To: Create a Service Account for an ASP.NET 2.0 Application.

How to configure the machine key in Web farms

You use the <machineKey> to specify keys and algorithms used by ASP.NET to protect Forms authentication tickets and ViewState. If you deploy your application in a Web farm, you must manually generate key values and ensure that the configuration files on each server share hashing and encryption keys.


To generate cryptographically random keys:

  • Use the RNGCryptoServiceProvider class to generate a cryptographically strong random number.
  • Choose an appropriate key size. The recommended key lengths are as follows:
    • For SHA1, set the validationKey to 64 bytes (128 hexadecimal characters).
    • For AES, set the decryptionKey to 32 bytes (64 hexadecimal characters).
    • For 3DES, set the decryptionKey to 24 bytes (48 hexadecimal characters).


The following code shows how to generate random key values. Compile the code to create a console application, and then pass the required key size as a command line argument expressed as the desired number of hexadecimal characters. Each byte is represented by two hexadecimal characters; therefore, to request a 32-byte key, pass 64 as a command line argument. If you do not specify an argument, the code returns a 128 hexadecimal character (64-byte) key.

// C# Example
using System;
using System.Text;
using System.Security;
using System.Security.Cryptography;

class App {
  static void Main(string[] argv) {
    int len = 128;
    if (argv.Length > 0)
      len = int.Parse(argv[0]);
    byte[] buff = new byte[len/2];
    RNGCryptoServiceProvider rng = new 
                            RNGCryptoServiceProvider();
    rng.GetBytes(buff);
    StringBuilder sb = new StringBuilder(len);
    for (int i=0; i<buff.Length; i++)
      sb.Append(string.Format("{0:X2}", buff[i]));
    Console.WriteLine(sb);
  }
}


For more information, see How To: Configure the Machine Key in ASP.NET 2.0.

How to lock configuration settings

To lock the configuration settings for all the Web applications on a Web server to prevent an individual application from overriding them, place the configuration settings inside a <system.web> element nested within a <location> element in the machine-level Web.config file, and then set the allowOverride attribute to false.


The following example enforces the use of Windows authentication for all Web applications on the server.

<location allowOverride="false">
  <system.web>
    <authentication mode="Windows"/>
  </system.web>
</location>


If you need to apply and lock settings for a specific Web application, use the path attribute on the <location> element to identify the Web application as shown here.

Important If it is critical that there are no cross-application breaches, it is better to configure the Web.config file in the /VDirName directory for locking the configuration instead of using the path attribute to lock the specific Web application.
<location path="Default Web Site/VDirName">
  <system.web>
    <authentication mode="Windows"/>
    <identity impersonate="false"/>
  </system.web>
</location>

If you specify the path, it must be fully qualified and include the Web site name and virtual directory name.

Personal tools