Encrypting information in ASP.NET configuration files
JM Alarcon
ASP.NET Visual Developer MVP
MsC Mechanical engineering and business consultant specialist, he has written several books and hundreds of articles on computer science and engineering in specialized press such as PC World, Windows Magazine, dotNetMania... JM is also a Microsoft Certified Trainer (MCT).

A frequently asked question is:
“How can I protect the information in my connectionstring if it’s in my web.config?”
First of all, I’d like to say that it’s always better to use the Windows Integrated Security (connection string with “Integrated Security=SSPI;”) instead of using SQL Server accounts, so in this case encryption is not necessary. In the other hand there is an IIS request handler which rejects the access to the web.config via HTTP, so the concern is that someone can see the configuration file through a security hole in our server or in the code, in which case the real issue is not the SQL Server credentials!.
Nevertheless, it’s important to know that in ASP.NET 2.0 or later we can easily encrypt any section in our web.config.
This can be done by code, but we are going to use the command line tool aspnet_regiis.exe, located in the folder “C:\Windows\Microsoft.NET\Framework\vx.x.xxxxx“. We just have to send the following parameters:
- encryption provider type that we want to use (-prov)
- the modificator “-pef” to indicate that we want to encrypt a physical path
- the section to be encrypted
- and the hard disk path where the web.config is located
For example:
aspnet_regiis.exe -pef "connectionStrings" "C:\myIISRoot\MyWebSite" –prov "DataProtectionConfigurationProvider"
In the example we are indicating the section to be encrypted (“connectionStrings”) in the web.config which is located in “C:\myIISRoot\MyWebSite”, using the DPAPI provider (more about it later).
Here is the result:
<connectionStrings configProtectionProvider="DataProtectionConfigurationProvider"> <EncryptedData> <CipherData> <CipherValue>AQAAANCMnd8BFdERjHoAwE/Cl+sBAAAAt ...... +hXziceYxOxY=</CipherValue> </CipherData> </EncryptedData> </connectionStrings>
(I removed most of the encrypted string because it’s too long)
The most convenient thing in this is that we don’t have to change anything in our code since ASP.NET automatically decrypts the string connection from the configuration.
With the -prov parameter (optional) we can specify the encryption provider we want to use. We’ll find two by default: “DataProtectionConfigurationProvider” (mentioned before), which decrypts using DPAPI (Windows Data Protection API) or “RsaProtectedConfigurationProvider” which uses a pair of public/private keys to encrypt and decrypt, this will be used as default if nothing is specified. We can build a provider class if we want to use a custom encryption and send it in the -prov parameter.
From my point of view, it’s better to use DPAPI since it’s a very safe encryption and is entirely tied to the machine where the process was done. This way although someone could read the web.config file or take it to another machine, it wouldn’t be decrypted.
Warning: Beacuase of what I’ve just explained about the DPAPI, you should perform this encryption process only in the server in which the application will be hosted, because if, for example, you encrypt a section in your development machine and then this file is moved to a production server, the section won’t be decrypted once in there. So, again, just perform this process in the machine where the application will be hosted.
Any section in the web.config can be encrypted, not only connection strings, however there are some exceptions:
- <processModel>
- <runtime>
- <mscorlib>
- <startup>
- <system.runtime.remoting>
- <configProtectedData>
- <satelliteassemblies>
- <cryptographySettings>
- <cryptoNameMapping>
- <cryptoClasses>
All other sections can be encrypted.
What if I forget how I encrypted it and I need it decrypted again?
No problem. We can use the same tool with the -pdf parameter to decrypt the data:
aspnet_regiis.exe -pdf "connectionStrings" "C:\myIISRoot\MyWebSite"
With this we’ll get the content of the section decrypted again.
I hope this is useful!



