0

I have a ConnectionString in my App.Config File which is encrypted by DataProtectionConfigurationProvider provider and Everything works fine In Solution A.

Then i build another Solution (Solution B) and add that App.Config File into it's project. and try to decrypt that config file, and surprisingly Everything works fine too! while i expect the second solution could not decrypt the ConnectionString.
Assume i deployed this project and in installation time, ask for SqlConnection Informations, Like USERID and PASSWORD then decrypt them and put it into App.Config File. everything is ok yet! But what would happen if someone else try to add generated App.Config File (in the end user machine) and decrypt my ConnectionString?
We try to encrypt such data so that no one else (except our program) can touch data.

  • is that Logical that someone touch my data using solution B?
  • If this is so, what can i do for keeping my data secure?
    ----------Editied ------------
    By the way, I'm using User-Level Decryption and the project is a Windows Application Not a Web Application
Rzassar
  • 2,117
  • 1
  • 33
  • 55

2 Answers2

1

The encryption key is stored either at the machine level or the user level (I am not sure how you decide which to use), so any program running on the same machine/user can decrypt the string.

You are using the wrong tool for the job, what DataProtectionConfigurationProvider is to prevent someone getting a data dump of your website/program (it is mainly used for IIS) and being able to connect using a different machine/user to your back end database.

Unfortunately I don't know what the "right tool for the job" would be for your case. It is extremely hard to "hide data from the computer the user is running on". The only suggestion I can make is go read this old question of mine where I ask a question similar to you and this old answer of mine where I answer a question about people hacking/cracking your application.

Community
  • 1
  • 1
Scott Chamberlain
  • 124,994
  • 33
  • 282
  • 431
1

Protecting the data in your app config, if you really want to be sure, means employing encryption with a key specific to your app, and storing the result in your config setting as a BASE64 encoded string.

Before writing the data, you'll have to use a text encoding to convert the text to an array of bytes. You then encrypt that array, then turn the resulting array into a base64 encoded string which you then store in your config.

Before inspecting the data, you'll have to decode the base64 encoding, decrypt the resulting information (a byte array), and then use the same text encoding to convert from the array of bytes to actual text.

If you really want to be a swine, you use an assymetric algorithm - encode with the private key, decode with the public key. That means that not only is the config data hard to read, it's IMPOSSIBLE to modify (because you don't give out the private key with your app - only the public one).

Martin Milan
  • 6,346
  • 2
  • 32
  • 44
  • the first solution (that was passing Through my head) is good but how can i tell some frameworks like `codesmith NetTier` or `Entity Framework` to decrypt that data first and then consume it as a ConnectionString? – Rzassar Sep 13 '13 at 16:27
  • You don't - the encryption of the connection string takes place outside of entity framework - totally independent of it. At run time, you decode the data, obtain a connection string, and then work with that. I'm not an entity framework bod, but I would be surprised if the DataContext doesn't come with some means of instantiating via a connection string... – Martin Milan Sep 16 '13 at 09:01