Secure, portable encrypted config values -- possible?

Question

I'm just curious if anyone has any great ideas on this.

We have a lot of C# windows services. Each app is installed on multiple machines (anywhere from 2-80, depending on the app.)

Due to the security setup of the network, we cannot (consistently) use Windows authentication to the SQL servers, so our connection strings and credentials have actual usernames and passwords.

Our infrastructure folks want to be able to do the following when deploying the software: 1) Edit the configuration once -- set the appropriate server, user, and passwords for various database connections. 2) Have the connection strings (at least) encrypted or otherwise unreadable to the naked eye 3) Copy that configuration file to all installations of a particular piece of software. This means that the encryption cannot be tied to a specific machine.

Can DPAPI do this? Can one set of keys be installed on all targets to allow the decryption of a common config file? How is the configuration edited in this case? How do you keep other users from viewing the encrypted configuration in the same manner?

Answer 1

I can comment on at least one aspect of your question, as we have a service configured this way where I work.

When editing/creating the configuration, we put a special token as the first character:

<value>:secret_password</value>

The colon is the special token. When the service starts and reads the configuration, it finds all the unencrypted values by looking for the token, encrypts them, and then overwrites the plain-text with the encrypted value.

So this allows the file to be edited, while keeping the secrets secret.

Answer 2

The DPAPI encryption uses the <machineKey> as the private key.

Option 1) You can update this in the machine.config of each server and set machineKey to be identical. This has wide impact to the server, such as with unrelated apps that depend on machineKey.

Option 2) You can override the <machineKey> in the web.config for narrower scope.

Session and encrypted viewstate validation also depend on the <machineKey>, so by having identical keys across servers, the sessions and viewstate will be mutually readable. This could be desired for a web farm of identical servers and a centralized session store, but that's out of scope of the original question.

How To: Configure MachineKey in ASP.NET 2.0

Answer 3

This sounds like a job for an X509 certificate.