ASP.NET 1.1 Security Guidelines - Sensitive Data

From Guidance Share

Jump to: navigation, search

- J.D. Meier, Alex Mackman, Michael Dunner, Srinath Vasireddy, Ray Escamilla and Anandha Murukan


Do not pass sensitive data from page to page

Avoid using any of the client-side state management options, such as view state, cookies, query strings, or hidden form-field variables, to store sensitive data. The data can be tampered with and viewed in clear text. Use server-side state management options, such as a SQL Server database for secure data exchange.


Avoid plain text passwords in configuration files

The <processModel>, <sessionState>, and <identity> elements in Machine.config and Web.config have userName and password attributes. Do not store these in plaintext. Store encrypted credentials in the registry using the Aspnet_setreg.exe tool.

For more information about encrypting credentials in configuration files and about Aspnet_setreg.exe, see Chapter 19, "Securing Your ASP.NET Application and Web Services." at

Note In ASP.NET 2.0, you can use the Protected Configuration feature to encrypt various configuration sections for protecting sensitive data. For more information on using the Protected Configuration feature in ASP.NET 2.0, see "How To: Encrypt Configuration Sections in ASP.NET 2.0 Using DPAPI" at and "How To: Encrypt Configuration Sections in ASP.NET 2.0 Using RSA" at


Use DPAPI to avoid key management

DPAPI is a native encryption/decryption feature provided by Microsoft Windows 2000. One of the main advantages of using DPAPI is that the encryption key is managed by the operating system, because the key is derived from the password that is associated with the process account (or thread account if the thread is impersonating) that calls the DPAPI functions.

Note In .NET 2.0, you no longer need to use P/Invoke. Instead, you can use the new ProtectedData class, which contains two static methods: Protect and Unprotect. For more information, see ".NET Framework Class Library - ProtectedData Class." at

User Key vs. Machine Key

You can perform encryption with DPAPI using either the user key or the machine key. By default, DPAPI uses a user key. This means that only a thread that runs under the security context of the user account that encrypted the data can decrypt the data. You can instruct DPAPI to use the machine key by passing the CRYPTPROTECT_LOCAL_MACHINE flag to the CryptProtectData API. In this event, any user on the current computer can decrypt the data.

The user key option can be used only if the account used to perform the encryption has a loaded user profile. If you run code in an environment where the user profile is not loaded, you cannot easily use the user store and should opt for the machine store instead.

The .NET Framework loads the user profile for the ASPNET account on Windows 2000. On Windows Server 2003, the profile for this account is only loaded if the ASP.NET process model is used. It is not loaded explicitly by IIS 6 if the IIS 6 process model is used on Windows Server 2003.

If you use the machine key option, you should use an ACL to secure the encrypted data, for example in a registry key, and use this approach to limit which users have access to the encrypted data. For added security, you should also pass an optional entropy value to the DPAPI functions.

Note An entropy value is an additional random value that can be passed to the DPAPI CryptProtectData and CryptUnprotectData functions. The same value that is used to encrypt the data must be used to decrypt the data. The machine key option means that any user on the computer can decrypt the data. With added entropy, the user must also know the entropy value.

The drawback with using entropy is that you must manage the entropy value as you would manage a key. To avoid entropy management issues, use the machine store without entropy and validate users and code (using code access security) thoroughly before calling the DPAPI code.

For more information about using DPAPI from ASP.NET Web applications, see "How To: Create a DPAPI Library," in the How To section of "Building Secure ASP.NET Applications," at


Protect sensitive data over the wire

It is important to consider how sensitive data such as credentials and application-specific data are transmitted over a network link. If you need to send sensitive data between the Web server and a browser, you should consider using SSL. If you need to protect server-to-server communication — for example, between your Web server and database — you should consider using either IPSec or SSL.


Do not cache sensitive data

If your page contains data that is sensitive, such as a password, credit card number, or account status, the page should not be cached. Output caching is off by default.


Personal tools