Question

What I would like to know is the definite approach to encrypting connection strings in a config file. Here are my questions:

1. Using machine-level encryption, can’t anybody accessing my server write a little .Net program to read the contents of the connection strings?

2. If I am deploying my application to users machines in an enterprise environment, and the application has connection strings in a config file, how can I make sure only my application can decrypt it? The scenario is especially interesting in a ClickOnce deployment scenario. I’ve read about people storing the config unencrypted at the publisher server and encrypting at the machine level when the app is downloaded, installed and executed for the first time. This sounds so wrong to me – connection strings zipping unprotected through the wire, and sitting unprotected for a brief amount of time between download and application execution.

3. Can I have a public and private key, sign my app, encrypt the config file with a key, and when the user executes it, decryption would only be possible from the signed application?

4. Since I am using ClickOnce, I could have my encrypted sensitive information in the code or embedded, because ClickOnce won’t detect a change unless the version # changes. So, if I need to recompile if I change my connection string, the point of an app.config is muted. What other approaches can I take, out-side using an config file, to achieve protection of the connection strings at the server, client and in between?

Answer 1

1. Yes. Secrets encrypted with the machine key can be decrypted by any process with access to the machine key. Secrets encrypted with the user key can be decrypted by any process started by the same user.
2. This is not possible. All contrary claims are snake oil. You application needs a secret to decrypt something. There are no known schemes to hide a secret inside an application. There are various obfuscation schemes, but nothing bulletproof. The best you can do is to raise the bar.
3. No. Either the application has the secret key to decrypt something, in which case you go back to point 2, or your application has the public key, in which case anyone can decrypt the same secret, so you basically do a validation of the configuration (was not tampered with), but the configuration is not secret.
4. You cannot deploy embedded secrets in an application securely. Is just a matter of how high is the price, if your protected asset (the secret) is worth it, then a hacker will get it.

The encryption infrastructure is designed to protect the secrets of the current user from other users. It is not designed to protect the secrets of an application from the user using it. What you ask for is not encryption, is DRM, and you need to look into the DRM infrastructure for answers. I’m not aware of a managed library around the DRM API.