tags:

views:

109

answers:

3

As all .net developers know its possible to encrypt values in web.config.

I have other XML configuration files, that I read in from serialization techniques, not using system.configuration but instead serializing to a strongly typed object.

Its now become a requirement for me to encrypt some values in these xml file, not the whole XML file, just some string values in the file.

All of this would be pretty standard stuff, except that this app is going to run on the client premises, and the client should be able to directly change configuration.

So. How can I go about setting up this encryption in such a way that the client can generate newly encrypted values into the config file, for example - a SQL connection string.

So far the best way I can think of is sending out a custom win form app, that can encrypt values, so that my app will know what to do with these values in a standardized way.

Can anyone improve on this idea?

+1  A: 

If you have an admin section of your web app, you could have the code that generates the encrypted value there, no need for a winform app.

Otávio Décio
This is a Web Service App, lets say I expose another web service to return the encrypting string. Do you think it could potentially be used to reverse engineer the private key?
JL
I use TripleDES for that, and I think it would be pretty hard to reverse straight from the results. Of course they can always fire off Reflector and see what you are doing, in which case you may want to think about doing this part in a safer manner.
Otávio Décio
Code is obfuscated, app is hardened down, so this would make the most sense I guess...
JL
+1 I'll have a look at TripleDES
JL
+2  A: 

The majority of the apps that I've seen that do exactly what you're talking about employ the same solution you suggest.

There is a seperate tool to administer the configuration of the application. It's cludgey, but that's what it takes to get the job done.

If you're talking about a web application with configuration that is not stored in the web.config, you could build the admin interface into the application. That way, your web app can handle the encryption and configurating your app looks and feels like part of the application itself (just like it should).

I think either one would work...the later is just more challenging to figure out.

UPDATE

Just saw the comment that you're talking about a web service app. In that case, you could expose services that are specifically used to configure the service application (would be difficult to implement). Or you could create a small web app that allows an Admin to configure the services (easier to implement). The last ditch effort would be the WinForms app (easiest).

And as long as your service takes the fields in an un-encrypted format and then encrypts them server side before storing them...you shouldn't have to worry about exposing any keys.

If you're going to allow them to request existing values, your services should return the un-encrypted values. Once again, the decryption is done server side so you're not risking exposing your keys.

Justin Niessner
+1 and accepted answer because it (a) means the client has less work to do (b) less risk of attack = win/win
JL
+1  A: 

We use a custom DLL to handle encryption in our apps. It could actually be built into the app itself, but we use it in many different projects so it's been moved out to it's own DLL. We just include a reference to it and away we go.

Just beware that if you go this route, if they (clients) wanted do, they could disassemble the dll and get to how you're performing the encryption. In our cases, we're fine with this risk since they're mainly just connection strings used to access data they already should normally have access to.

Josh W.
+1 agreed, its not so much the client I am worried about, but you always get some tech admin who works for client who will get sarky if he finds connection strings getting stored unencrypted....
JL