Encrypting web.config using Protected Configuration pointless?

5
votes

I must be missing something...

So I am in the process of figuring out the best way of encrypting the database connection string and sql session state connection info in web.config. I quickly find a walk through on msdn explaining using protected configuration to encrypt parts of the web.config: MSDN walkthrough on using Protected Configuration

So I am thinking great, there is a mechanism in place to do this and it looks very simple. I get to the end of the walkthrough, and they provide the source code for an aspx page that can be used to decrypt all the connection strings!!!!

What is the point??? I dont have any ftp service running on this web server, the only way anyone is going to see web.config is if they have access to the file system where the website is published. If they have that then all they have to do is use the provided code to unencrypt.

What am I missing? Is there a better way to encrypt these? If i roll a custom solution will it work for the sql session state part? (dont believe that cane be removed from web.config)

1
.netasp.netsecurityencryptionweb-config

1 Answers

6
votes

You need at least write access to the filesystem to be able to decrypt it, assuming you're using the DPAPI provider. Ways to decrypt it include:

  • Copy an aspx page containing decryption code to the server and navigate to it
  • Log in on the server and run an application to decrypt it.

But it protects against decryption by an unauthorised user who has read access to the filesystem or a backup of the filesystem.

Typically you would set up your production servers so that only authorized adminstrators can log in to the server or write to its filesystem.

Developers might have remote read access for support purposes, and would not be able to decrypt the config file remotely.

Encryption/decryption is easy with standard libraries: the hard part is ensuring only authorized people have access to the keys.

If you're using DPAPI, you're essentially delegating management of the keys to Windows security. If you use another provider such as RSA, you need to store the key somewhere, and protect it against unauthorized access e.g. using an ACL.