Why is App.config a safer place to store the connection string than in the source code?

A simple question, I know that saving the connection string in text form in the source code is bad, because someone can use a tool like Ildasm.exe to decompile and then view your connection string, but why is the application used. configure any more secure?

Of course, this configuration file is next to your executable file, so if someone has access to your executable file for decompilation, they also have access to your configuration file and therefore to your connection string.

So my question is: why is App.config a safer place to store the connection string than in the code?

+4
source share
3 answers

You can protect any information in the configuration file. This link is for a walkthrough. Encrypting configuration information using a secure configuration explains how

UPDATE: Sorry for the broken link, I update it and add the title of the article. The solution uses RsaProtectedConfigurationProvider . I created a simple method in my helper class WebUtility:

public static void CheckWebConfigSecured(string webPath, params string[] sections) { Configuration confg = WebConfigurationManager.OpenWebConfiguration(webPath); bool done = false; foreach (string section in sections) { ConfigurationSection confSection = confg.GetSection(section); if ((confSection != null) && !confSection.SectionInformation.IsProtected) { confSection.SectionInformation.ProtectSection("RsaProtectedConfigurationProvider"); done = true; } } if (done) { confg.Save(); } } 

I am calling from Global.asax.cs in Application_BeginRequest

 WebUtility.CheckWebConfigSecured( context.Request.ApplicationPath, "connectionStrings", "appSettings", "log4net"); 

If connectionStrings, appSettings and log4net are the web.config sections that I want to protect.

As a result, these sections in the Web.config file on the server look as follows, after the first visit to the site after deployment:

 <appSettings configProtectionProvider="RsaProtectedConfigurationProvider"> <EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element" xmlns="http://www.w3.org/2001/04/xmlenc#"> <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc" /> <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#"> <EncryptedKey xmlns="http://www.w3.org/2001/04/xmlenc#"> <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" /> <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#"> <KeyName>Rsa Key</KeyName> </KeyInfo> <CipherData> <CipherValue>YbjvJF6IpTaEFb58ag1O ... HJm1uzA=</CipherValue> </CipherData> </EncryptedKey> </KeyInfo> <CipherData> <CipherValue>mzJ2PoteOG7ZpAs922sounmG ... 02D3ZiM1PCliSw==</CipherValue> </CipherData> </EncryptedData> </appSettings> 
+3
source

App.config as such is not more secure if you leave the connection string in clear text. However, you can encrypt parts of the configuration file, which will improve security.

http://msdn.microsoft.com/en-us/library/53tyfkaw.aspx

http://www.codeproject.com/Articles/18209/Encrypting-the-app-config-File-for-Windows-Forms-A

You can also save the connection string in an encrypted registry key if you do not want to store it in a file in the application folder.

0
source

Saving the connection string in code in a literal string is easily extracted from the compiled binary using a simple hex editor, unless the binary was confused.

App.config is not necessarily more secure, but it is possible to encrypt information in App.config, which will be much more secure than plain text.

App.config can also be protected at the ACL level in the file system. This can complement security, but is not always practical, as usual, host server administrators will have permission to file.

0
source

All Articles