Where / how can I save the SQL Server connection string so that it is reliably accessible to remote applications?

Question

We have .net applications running on many machines. The db connection string stores an XML settings file for each of them. Each application starts and as a first step loads this line from the settings file. It works great, but if we ever had to change our registration information, it would be a nightmare to find all the places we saved over the years. In addition, with virtual machines, we are constantly adding new machines, and it would be ideal to simply deploy exes / dll and have the application automatically and reliably receive a connection string.

I considered encrypting the string and placing it on our web server, so remote applications can receive it through the http and dns name and decrypt it, but this is quite simplified, and since security is important for this part of the information, I need to be very careful.

So the question is, how do you safely decrypt the connection string in remote applications, so when they start, will they know to get to db? Once they can do this, they can get additional settings from the configuration table in the database.

Answer 1

What parts of your system do you trust? You have to trust your clients 100%, because as soon as they have a connection string (which they should have), they can do anything in the database that they want. You must also trust the servers.

So it seems you trust everyone. This simplifies the security of the system: it is already safe, no matter how you distribute the connection string.

I have seen a lot of superstition when it comes to storing and distributing passwords and connection strings. Many people find it inconvenient to send and keep them clear. This is irrational because customers end up having it explicitly. It is impossible to prevent.

So, my advice: Make a simple web service providing the following API:

string GetConfigSetting(string name) 

Clients can request this service for a connection string. This service is so simple that its interface is likely to never change.

In this case, it makes little sense to worry about encryption. The client application can be easily decompiled to access any decryption procedure. In addition, the client must ultimately decrypt the secret. At this point, the attacker controlling the client machine can read the secret explicitly.