"Static" Encryption of an application configuration file in C#

Question

This is an issue I've been thinking about and searching around the internet for some months now.

In the specific szenario I have an application on a network share that connects to a database in order to retrieve some information. The connection string for the database is static, including username and password for establishing a read-only connection to the database. Clearly, the connection string can't just be stored in plain text but has to remain the same for all users that start the app from different computers around the network.

And this is the nut I failed to crack in a satisfying way:

All tutorials I've found so far are using the build in .net-functions for protecting the connection string section of the app.config file (like RSAProtectedConfigurationProvider), which is great for user-scope encryption but can't be used for the described scenario as the rsa container is generated for a specific user/computer an thus only this one user/computer is able to read from the once encrypted config file - or am I missing a point here?

My final attempt was to write a somehow obfuscated method to generate a static string inside the application, encrypted my connection string with it and call it every time a database connection needs to be established. That does the job but isn't very hard to be hacked by simple decompiling the program, extract the encryption/decryption method apply it to the also extracted connection string.

I was wondering if there is some technique to protect sensitive data like connection strings inside the applications scope so it is only known by the app itself and static for all users BUT can't be extracted by simply decompiling the program.

Maybe I'm thinking completley inside the wrong box here, but I find it pretty obscure that it seems like there is no out-of-the-box-solution for this pretty commonly seeming problem.

Answer 1

You're correct. There is no way to protect your encrypted data 100%, unless you can keep your encryption key 100% secret. Obfuscation or "securing by obscuring" is going to remain your best option in such a scenaruio, unfortunately.

As an alternative, you should decouple your shared app from the database by creating a web service for your data layer and make your app access that service instead of going directly after your DB. The simplest way to protect the web service is to enable integrated Windows authentication for it and make sure your client app utilizes default user's domain credentials when accessing it, using the Credentials Cache. The implementation is trivial in .NET.

The web service scenario is also preferable from the point of scalability and performance, especially if your client app instances are to be running from different offices: it is highly inadvisable to make direct database calls over a WAN link or Internet, as that protocol is extremely chatty. A web service that is co-located with your database is a much better solution, especially when using remote clients, as all calls are downgraded to a single request-response type of traffic for each call. (Or, possibly, two roundtrips, when authentication is in play.)