ADO.NET 2.0 Security Guidelines - Sensitive Data

From Guidance Share

Jump to: navigation, search

- J.D. Meier, Alex Mackman, Blaine Wastell, Prashant Bansode, Chaitanya Bijwe


If You Need to Store Sensitive Data, Encrypt It

Avoid storing sensitive data in the database, if possible. If you must store sensitive data, protect the data by using encryption. Use a strong symmetric encryption algorithm such as AES to encrypt the sensitive data before storing it in the database. Use DPAPI to encrypt the symmetric encryption key, and secure the encrypted key in a protected location such as the Windows registry in a key that has an ACL that restricts access to your application's process account.

Symmetric encryption requires the generation and secure storage of a key to be used for encryption. As far as possible, a new key and initialization vector (IV) should be created for every session and should not be stored for use in a later session. A new key and IV are automatically created when you create a new instance of one of the managed symmetric cryptographic classes by using the default constructor.

Note SQL Server 2005 includes support for data encryption directly in the database.


Protect Sensitive Data over the Network

Sensitive data passed across the network to and from the database server could include application-specific data or database login credentials. To ensure the privacy and integrity of data over the network, either use a platform-level solution, such as that provided by a secure datacenter where Internet Protocol Security (IPSec) encrypted communication channels are used between servers, or configure your application to establish SSL connections to the database. The latter approach requires a server certificate installed on the database server.

  • Use SSL when you need granular channel protection for a particular application, instead of for all applications and services running on a computer.
  • Use Internet Protocol Security (IPSec) to secure the communication channel between two servers and to restrict which computers can communicate with one another. For example, you can help secure a database server by establishing a policy that permits requests only from a trusted client computer, such as an application or Web server. You can also restrict communication to specific IP protocols and TCP/UDP ports.


Store Hashes with Salt Instead of Storing Passwords

Do not store user passwords either in plain text or encrypted format. Instead, store non-reversible password hashes with salt. By storing your password with hashes and salt, you help to prevent an attacker that gains access to your user store from obtaining the user passwords. If you use encryption, you have the added problem of securing the encryption key. For ASP.NET applications, use one of the membership providers to help protect credentials in storage and where possible specify a hashed password format on your provider configuration.

If you must implement your own user stores, store one-way password hashes with salt. Generate the hash from a combination of the password and a random salt value. Use an algorithm such as SHA256. If your credential store is compromised, the salt value helps to slow an attacker who is attempting to perform a dictionary attack. This gives you additional time to detect and react to the compromise.

Personal tools