Options for protecting connection strings

Question

Just a general architecture question.

I know that for websites you can use the functions built into IIS to encrypt the connection string section. However, I'm not sure what it is ... If I do this and then copy the web.config file to another project, will the new project decrypt the string of connection strings in the configuration file?

Where this becomes a problem is access to a production database. We do not want anyone to be able to copy the configuration file from production to their project and have access to the blank check in the production database.

My company is currently doing this to save the encrypted connection string in the server registry, and then use a makeshift tool to read the registry and decrypt the value on the fly. This prevents someone from simply looking at the registry or web configuration to see the connection string.

Also, for wide client applications (WinForms, WPF, etc.) this may be a little more problematic because once again I am not sure if the IIS trick will work since the applications will not work in IIS. We currently have a kludgy solution for this, which is related to the same home application, but reading the encrypted string from the binary and decrypting on the fly.

This seems to be very encrypted and we are looking for the best way to do this (e.g. industry standard, current technologies, etc.).

So, a more general question is ...

What approaches did you use to protect your connection strings? Especially when it comes to access to several types of applications, encryption, etc.

Answer 1

A quick Google search will show that other people are trying to encrypt any or all of the application’s configuration file (that is, Google “files to configure application files to protect against infection").

But more often than not, I find that the best answer is to properly provision the resource you are worried about (usually a database). Windows authentication is always preferred for SQL authentication, so passwords should not be stored in the configuration file, although this may not always be an option. If you want to restrict access to a resource (especially if it is usually accessed through some kind of web level, for example, a web service or the website itself), then place the resource on another server (which is preferred in any case) and do not allow access to it from outside the internal network. If an attacker has access to your internal network, then there are usually more problems than this one resource that you are trying to protect.

If you are concerned about a malicious person performing an action that even your application cannot perform (for example, deleting a database), make sure that the credentials that the application uses also do not have this permission. This, obviously, does not prevent the attack, but can reduce the amount of damage it deals.

Protecting the information stored in the configuration file, which is located on the user's computer, is usually not worth the time, IMHO. In the end, the machine itself will have to be able to decrypt the information, and if the machine has the means to execute it, then the user. You can make it difficult for the user, but it is usually still possible.

This is actually not a direct answer to your question, but I hope that it makes you think of a different path that might lead to an acceptable solution.

Answer 2

As I understand it, protecting encrypted connection strings, as shown in the article Importing and Exporting Secure Configurations RSA Key Containers , protected the user-level connection string.

This means that only the account running IIS ( NT AUTHORITY\NETWORK SERVICE ) can access cryptographic keys to decrypt the connection string. Therefore, this is protected only from users who can log into the server containing the web.config file. But it can be expanded to restrict access to a specific application.

As for the fat client, the interface may be slightly narrowed:

Define all SQL commands as stored procedures on the server and change the settings for the user account you use to enable these stored procedures. This will restrict access to the database for operations that can be performed using credentials to log into the SQL system.

Answer 3

I would use SQL DB account management functions with specific permissions (for example, on the most abstract - allow execution of only SQL commands for reading) and only from allowed hosts and / or areas.