The other day, I had a request from a client to secure sensitive information in the configuration files. I have to admit, as far as security tightening goes, encrypting the config files isn’t at the top of the list of our tasks. When we deploy we go through a bunch of different benchmarks to make sure the server is secure, and entry from outside is difficult. However, the client was particular about this, and even though I have done this for custom .net sites before, I had never done this for Sitecore applications. I decided to investigate and try to formulate a plan for this.
Note: one of the ways to secure the connection strings for the database on sitecore is to use windows authentication, so the passwords are not in the config file.
First we have to figure out what we actually want to protect. The first instinct is to encrypt the entire web.config file, but that is a little overkill – its not a bad idea, but so much of it is standard .net settings, and I’m not entirely sure about the performance hit. The most obvious sensitive information is connection strings, and usernames/passwords for other integration.
If you have usernames/passwords for integration, they would all need to be in the appSettings section (or in a separate ConfigSource file). The connection strings are already in a separate file for Sitecore, so that makes things easier.
If you are using WFFM (Web Forms for Marketers) module, the connection string is in an include file called forms.config. This was a little messy, so I searched around for a way to have this in the connectionStrings.config file. I eventually found it in Sean Kearney’s Blog – you can add it to the connectionStrings file. This was an older version of WFFM, so if it does not work, there is another way (requires custom coding) that I found here: http://kamsar.net/index.php/2013/10/make-web-forms-for-marketers-use-a-regular-connection-string/
After this re-arranging is done, you are now prepared to encrypt the files. Now, as I mentioned before, we have to figure out what we want to protect. If you are trying to protect the information from your developers, that means that you have to have the encrypted version in your source control. If you are only trying to have the encrypted versions on the servers, then you can do the following on the servers, or as part of your build process. I am only covering the encryptions of the two main sections, connectionStrings and appSettings, as this is where all of my sensitive information is. You cannot encrypt all the different sections, but you can definitely encrypt the two above. You can also encrypt the sessionState section, which could also have a database connection string.
The server side method to encrypt the files is to use the aspnet_regiis utility, using the default RsaProtectedConfigurationProvider that .net is installed with.
Run the commands to encrypt:
aspnet_regiis.exe -pef "connectionStrings" . -prov "RsaProtectedConfigurationProvider" aspnet_regiis.exe -pef "appSettings" . -prov "RsaProtectedConfigurationProvider"
Once you encrypt, you don’t have to decrypt in code, as IIS takes care of this for you. If you did need to decrypt, you would decrypt using:
aspnet_regiis.exe -ped "connectionStrings" . -prov "RsaProtectedConfigurationProvider" aspnet_regiis.exe –ped "appSettings" . -prov "RsaProtectedConfigurationProvider"
The above uses a default encryption provider RsaProtectedConfigurationProvider, which uses the default key that comes with .net, which is NetFrameworkConfigurationKey
To make it a little bit more secure, you can generate your own key using:
aspnet_regiis.exe -pc "NameOfKey” –exp
You can export the keys from another machine and then import as well:
To Export:
aspnet_regiis -px "NameOfKey" "c:\keys.xml" –pri
To Import:
aspnet_regiis -pi "NameOfKey" "c:\keys.xml"
Then give permissions to the apppool that is running the website to read the key:
aspnet_regiis.exe –pa “NameOfKey” “[AppPool Identity]”
Usually [AppPool Identity] is in the form IIS APPPOOL\[name of app pool]
To find the identity of the apppool that is being used on your site, put the below script in a .aspx file in the root of your website and it will output the identity that you can use.
<%@ Page Language="C#" %> <% Response.Write(System.Security.Principal.WindowsIdentity.GetCurrent().Name); %>
Then add this in the web.config in the configuration section, right after where configSections end:
<configProtectedData>
<providers>
<add name="MyProvider"
type="System.Configuration.RsaProtectedConfigurationProvider, System.Configuration, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL"
keyContainerName="NameOfKey"
useMachineContainer="true" />
</providers>
</configProtectedData>
Then run the above encryption commands, using MyProvider, instead of RsaProtectedConfigurationContainer.
That should effectively secure your configuration files if somehow a hacker was able to get to them via the web. This is one of the easier ways to do this, and I’d love to hear different approaches for this. Drop me an email, or leave me a comment if you have a better approach for this.
The Runtime Report 