To encrypt configuration information in ASP.NET 2.0, keep the following things in your mind:- All forms of encryption involve some sort of secret that is used when encrypting and decrypting the data. Symmetric encryption algorithm use the same secret key in both encrypting and decrypting a message, whereas asymmetric encryption algorithms use different keys for encrypting and decrypting. Regardless of the technique being used, the encryption scheme is only as safe as the secret key for decrypting.
- The configuration encryption capabilities in ASP.NET 2.0 are designed to foil a hacker who somehow is able to retrieve your configuration files. The idea is that if the hacker has your Web.config file on his computer, she can't de-scramble the encrypted sections. However, when an ASP.NET page on the web server requests information from an encrypted configuration file, the data must be decrypted to be used (and this happens without you needing to write any code). Therefore, if a hacker is able to upload an ASP.NET web page to your system that queries the configuration file and displays its results, she can view the encrypted settings in plain-text. (There's an example ASP.NET page that can be downloaded at the end of this article that illustrates encrypting and decrypting various sections of the Web.config file; as you'll see, an ASP.NET page can access (and display) the plain-text version of the encrypted data.)
- Encrypting and decrypting configuration sections carries a performance cost. Therefore, only encrypt the configuration sections that contain sensitive information. There's likely no need to encrypt, say, the <compilation> or <authorization> configuration sections.
Encryption Options:
Protecting configuration sections in ASP.NET 2.0 uses the provider model, which allows for any implementation to be seamlessly plugged into the API. The .NET Framework 2.0 ships with two built-in providers for protecting configuration sections:
*
The Windows Data Protection API (DPAPI) Provider (DataProtectionConfigurationProvider) : this provider uses the built-in cryptography capabilities of Windows to encrypt and decrypt the configuration sections. By default this provider uses the machine's key. You can also use user keys, but that requires a bit more customization. Since the keys are machine- or user- specific, the DPAPI provider does not work in settings where you want to deploy the same encrypted configuration file to multiple servers.
Refer this Microsoft link on "
How To: Encrypt Configuration Sections in ASP.NET 2.0 Using DPAPI" for more information on this process.
*
RSA Protected Configuration Provider (RSAProtectedConfigurationProvider) : uses RSA public key encryption to encrypt/decrypt the configuration sections. With this provider you need to create key containers that hold the public and private keys used for encrypting and decrypting the configuration information. You can use RSA in a multi-server scenario by creating exportable key containers.
Refer this Microsoft link on "
How To: Encrypt Configuration Sections in ASP.NET 2.0 Using RSA" for more information on this process.
There's one more option on encrypting the configuration information in the web.config, it's done through
Programmatically Encrypting.
Please go through this link for more info on this type of encryption : davidhayden.com/blog/dave/archive/2005/11/17/2572.aspx
Once the data is encrypted, when it's read from an ASP.NET page (i.e., reading the connection string information from a SqlDataSource control or programmatically, via ConfigurationManager.ConnectionStrings[connStringName].ConnectionString), ASP.NET automatically decrypts the connection string and returns the plain-text value. In other words, you don't need to change your code one iota after implementing encryption. Best of Luck 