I opted for WCF 4 Step by Step by John Sharp, as I had purchased the previous WCF book he published a few years ago. I did like his thorough style because I needed to learn it from scratch.
In Chapter 4, “Protecting an Enterprise WCF Service”, he uses some examples where you enter your domain, username and password directly into the code(!). BUT – he does have a warning on every code sample:
Warning: This code is for illustrative purposes in this exercise only. In a production application, you should prompt the user for their name and password. You should never hard-code these details into an application.Now, I do nearly all of my development on my work laptop. The thought of someone just searching my computer remotely for files with my well-known domain and username puts me off completely. So instead, I decided to apply encryption to it and looked for a way which did not require me to write another program.
Using existing tools to apply the encryptionIn the TS: Web Applications with the .NET Framework 4, they discussed how to encrypt the
<connectionStrings>section in your web.config. However, I want to leverage this to encrypt my
First thing, start up a Visual Studio Command Prompt and CD to your location. We want to rename the app.config (prior to the build process) to web.config. For this example, we’ll assume my application in development is at
C:\> cd C:\Projects\EncryptConfig C:\Projects\EncryptConfig> ren app.config web.configNext is to leverage the encryption utilities in the aspnet_regiis utility. All we provide is the section to encrypt and the file to apply the encryption to:
aspnet_regiis –pef “appSettings” .The
–pefindicates we want to encrypt a specific section and provide the filename. If you have CD’d to the directory, you can just use
–pe “appSettings”and it will look for the web.config file.
The next step is to rename the file back to an app.config:
ren web.config app.configYou will notice that the app.config has encrypted this section like this:
<appSettings configProtectionProvider="DataProtectionConfigurationProvider"> <EncryptedData> <CipherData> <CipherValue>AQAAANCMnd8BFdERjHoAwE/Cl+sBAAAAaUZOOb4EQkGNPyy5tzAjBgQAAAACAAAAAAADZgAAwAAAABAAAADQc+YHWZxsOuA55uoTOnvLAAAAAASAAACgAAAAEAAAAPYMaWCQj/hrK3T9DwGH2rxQAQAAyGBicUMztQUL+3cm7QJa5Nxf0NIlHv8WcT7rog67OaMFFc09qVZjmoloAaSsSZMLJC+Xof42NQ1H+x90kOASWvyWibqXkczP7bIy5/9whKb9T0eoHgpnqKu+WmiQQCf7pnM5XIY25TJ1uxzSu+pWZfabLkzfFZah6PaT/fLNCR7DLraewvX7LMmQk2+YLhEot+RDrXAtum7qpCweFFLCS8g8L9tTpz/XzKFjaXJqlJAGru8f9+PgEDOBCVxic8cvzjKizyxSQlS55ht0bJUD1NO6LGOQwtek7SKX2DjOCqQoWGf1uVXePtft73eN+JY7wcCjftu6IWQqUYdj2DMCFn6vZhaNYF5TkHtKv4kpZtNer+s50Yc8E2uUPq99ZZ8vZQMiGdQ8xopIWwx5F/WFUxpeQ5/hG4A4IKhY2njSC3m/efH4M28MWET34HTXVx1gFAAAAGC4o4MxMGI73etkgTMojENDadwS </CipherValue> </CipherData> </EncryptedData> </appSettings>The thing to note here is it is using the
DataProtectionConfigurationProvideraccesses the Data Protection API which is a user-specific API. It is fine as long as you always log in with your user, on your domain. But if you tried to distribute this application, the section would never be able to be read by another computer.
RSAProtectedConfigurationProviderallows you to encrypt specific to the user or the machine. It also allows you to export the key so that it can be moved to another machine. This would be useful over a web farm (this is an IIS tool after all), where the
<machineKey>can be shared across computers.
In any case, if you are looking to distribute this application and encrypt the contents of a configuration file, be sure you understand what encryption methods are available to you.