Encrypting configuration on shared IIS7 hosting that uses load balancing

Question

When hosting a site on a cluster (or cloud configuration) we need to specify a Machine Key in the web.config file. This is needed to keep the machines in sync (often the first encounter with this is when you have to log in repeatedly after every one or two page loads).

Some say it's no use at all to encrypt the web.config on shared hosting. Others have some good points (watch out for editors that save .bak files for example).

Apart from database credentials, the config may contain some other credentials that may be of more direct use to an attacker, like root-admin credentials for forms-authentication (used for making and restoring database backups for example, where the user must be able to log in without relying on the database).

Is it possible to encrypt these sections with the provided means, since the "machine key" is defined in the same config file? If that key be used we have a nice chicken-egg paradigm!

It's shared hosting, so running aspnet_regiis is out of the question. I've also seen a lot of "Object already exists" and "key container could not be opened" problems on shared hosting when attempting to programmatically achieve encryption on projects that did not even utilize load balancing.

My question is, is it technically possible to encrypt the sections on shared- load-balancing (machine key in config) hosting with the standard instrumentation or should I spare any efforts.

Answer 1

Encryption is possible however at some point you must have a private key or a password that you need to use to decrypt the encrypted data. So the question is where do you put it?

In IIS you could store a certificate private key in a certificate store but in a shared hosting environment you probably don’t have that type of access. Also if you are trying to protect the data from the hosting provider they can easily get access to the key. If you are trying to protect a database connection password, being a hosting provider they probably host you database too so that won’t help. I would however always salt and hash any passwords that would be entered in a login prompt stored in the web.config. Remember you don’t actually need to decrypt them, only salt+hash in the same sequence and compare.

You may still choose to encrypt the data as it may not be apparent what it is to the casual observer, however it would be trivial to break if they is what they intended.

Hope that helps.