Assuming you are running your website on windows and IIS it is possible to encrypt your web.config file with a little bit of scripting during your website deployment. However I would always ask why do you want to do this? IIS will not serve this file by default and if you are sensible your production websites file system should be well secured already. But assuming you have a good reason, here is how.

It can be done section by section during a deployment using the aspnet_regiis command. For example to encrypt the connection strings section for YourApplicationName

aspnet_regiis -pe "connectionStrings" -app "/YourApplicationName" -prov "RsaProtectedConfigurationProvider"

Once run it means that someone who has the config file cannot see all its contents. So if the file gets passed around the company it's secrets are probably safe. However if someone malicious got hold of this file then probably they were an admin on your webserver and then they could trivially decrypt the contents by issuing the reverse -pd command, so this is not the substitute for properly securing your server.

If you are using Octopus Deploy then there is also an octopus step to automate this so you can build it into you CI pipline.

Be aware you may find there could be a maintenance overhead because debugging deployment issues caused bad credentials would be harder as you could not see the configuration values and spot the mistake. Having an optional step at the end of a deployment that you could opt out of (again easy if using octopus) would make this less hassle-some.

As far as I see it the only security gained by doing this is that a web.config that is moved off the web server is still secure. You should be realistic about how often this happens and the size of risk to your live database connection details. If you are a bank then sure, for a blog it is probably not worth it. Given the effort involved I would have thought the time would be better spent doing other security hardening work, e.g. removing passwords from source control if you have them there, adding https everywhere, penetration testing etc.

As for config outside of websites/IIS, then it is a bit more involved. More info on John Galloway's blog.

Reference: MSDN: