Encrypting configuration information using protected configuration provider [closed]

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center. 开发者_运维技巧 Closed 10 years ago.

When using a protected configuration provider to encrypt configuration information in a app config file, what encryption is used?

What alogorithm and key is used to encrypt and decrypt the information?

Update

Ok, i've read the links provided by Sani Huttunen and read these here and here.

So the RSAProtectedConfigurationProvider uses TripleDes and RSA encryption and

DpapiProtectedConfigurationProvider uses TripleDES.

RsaProtectedConfigurationProvider uses the machine account or the user account and DpapiProtectedConfigurationProvider uses the user's logon password as the key for encryption and decryption.

I see this would work fine for a asp.net web app. But what about windows applications?

I was lead to believe that all my connection strings should be saved in the app.config file and then encrypted using a protected configuration provider.

But if you deploy your winforms app to another machine it would not be able to decrypt the connectionstring becuse the key was based on the developer's logon password and saved in a keyfile not deployed with the application. or if the keyfile is deployed with the application then anyone can decrypt the app.config file.

Is this correct? So what's the point in using this method?

What's the method for protecting information in an app.config file for deployed windows applications?

---

You may want to read all about it here.

There are two providers in the .NET framework:
DpapiProtectedConfigurationProvider
uses the Windows Data Protection API (DPAPI) to encrypt and decrypt data.

RsaProtectedConfigurationProvider
uses the RSA encryption algorithm to encrypt and decrypt data.

---

What problem is your winform app trying to solve?

You have two conflicting problems. You need to distribute an app to someone who is untrusted. And you need a trusted connection to the sql server.

Even if you encrypt the connection string, if you have the key to decrypt it stored somehow on the same machine, then your user can decompile your app and work out what it is.

Even if the connection is read only then it is still vulnerable to SQL injection attacks.

What may be a better solution is to have some restful api. That would give your user a well defined api of things they can do. You can then manage users and the things they are allowed to do (i.e., can update their details but not someone else, but still can read everyone's public stats).

Have a look at http://wcf.codeplex.com/wikipage?title=WCF%20HTTP for an easy way to create a safe api.

(If you give some more details, I can modify my answer with a solution that may work better for your needs.)

---

It is tricky. If you want to encrypt something then you need to manage the key(s) you used to encrypt it with.

DpapiProtectedConfigurationProvider off loads this to the OS, which is effectively using the password of the user to keep the key protected. (However you are then bound to that account or machine)

RsaProtectedConfigurationProvider Is similar but provides a way of exporting the public/private key pair. So you can add(import) that to another machine.

However this again gets tricky, in that if you want to move the app to another machine you need to copy the public/private key pair. This is fine if you (or someone you trust) can do that, and delete the key container afterwards. Remember that if anyone gets hold of that key container, you are back to square one.

If you are using Active Directory (I think) you may be able to set up a user account(across all your machines) which your app runs under. This would then allow you to use DpapiProtectedConfigurationProvider. In fact you may be able to use Active Directory to deploy your key container for RsaProtectedConfigurationProvider securely as well. (I am not an expert in AD, you will need to google that yourself)

Using SQL Server Integrated Security is another option. This lets you do away with storing the credentials all together. (If you can this ma be the best option).

The other option (this is what I am doing for the project I am working on. YMMV) is to implement a ProtectedConfigurationProvider.

I don't have control over AD and installing keypairs wont fit into our deployment work flow. So in my case, when the app tries to get the connection string from the config it looks in the registry. If it finds a plaintext password there, (Do not ask why, but this can fit into our deployment work flow), it encrypts it using DPAPI, but to the machine that the app is deployed to. It then puts this into the web.config and deletes it from registry. So I did need to type int the credentials once. But running the app, causes it to be encrypted, but only decryptable by that app on that machine.
at That works from my peculiar set of circumstance. However the recommended solution would be to use SQL Server Integrated Security if you can.