In this post, I would like to explain why it is good to encrypt connection strings, but only in specific case.
DPAPI to be protected
To make a long story short, connection strings are usually encrypted during the installation using DPAPI (Data Protection API). The command line that encrypts the data is defined below:The result of running the command above is illustrated in the screenshot below:
DPAPI to be unprotected
DPAPI mainly protects from user that has LOCAL access to the operating system (remote access to config files is prohibited by default in IIS). In this case, since DPAPI encrypts the data using user's\machine's store, the decryption can be executed as follows:
1. If the data encrypted in the user store, then it can be decrypted using the same user credentials.
2. If the data encrypted in the machine store, then it can be decrypted in the local operating system only.
Henceforth, the malicious user is able to execute the following command in order to decrypt the data:
See the result below:
DPAPI is good, but only in specific case
In order to protect connection strings, it is important to understand that the protection should be based on both application settings and operating system's hardening.
If the operating system is not hardened, the following (but not limited) bypass methods can be executed:
1. Direct access to DB server.
2. Ability to run "aspnet_regiis" to decrypt the connection string.
3. 3rd party heap inspection tools can be executed in order to see the cleartext connection string in the memory (unless it overloaded somehow to SecureString value).
Thus, I recommend to harden the operating system, specially in the authorization section. In addition, I think that using white listing application control (e.g. Bit9 Pairity) can protect against the 3rd attack from above.
In addition, I recommend to read the nuclear solution in the code.