Do I need to protect the connection string in web.config?

Question

So, I am using connection strings in my web.config using SQL authentication.

Of course, people say that this could be a vulnerability, because you store the password in clear text.

However, from what I know, IIS never serves web.config, and web.config should have read-only access to administrators and IIS. Therefore, if the hacker gained access to the web server, it does not matter which encryption I use, because the private key will be on the web server.

Would encryption of the connection string be classified as protection through obfuscation?

Should I encrypt the connection string web.config and store the private key on the web server?

In addition, of course, if I do not use SSL, I pass the connection string over HTTP in text form. If I use SSL, this problem should also be mitigated.

Answer 1

I would not say that storing a plaintext password in Web.config is a security vulnerability in itself. But password encryption is a useful defense in depth, and not just security through obscurity:

• What if IIS is not configured correctly to serve Web.config?
• What if a security vulnerability is discovered in ASP.NET (for example, missing an oracle vulnerability ) that allows anyone to download Web.config?
• There is varying degrees of access to the web server, from full administrative privileges to entering server-side code. If an attacker manages to do this, he will be able to read Web.config, but will not be able to access the machine keys, especially if your application runs under private trust.

In the end, it's up to you whether the risk of storing plaintext passwords in Web.config is acceptable. Of course, if Windows authentication is an option, then you might want to use this instead of SQL authentication.

UPDATE:. Speaking of security, it is helpful to identify assets and threats. In this case, the asset is confidential data in the database (if the data is not significant, then why worry about protecting it with a password?), And the threat is the possibility that the attacker will somehow gain access to Web.config and, therefore, to the database data also. A possible mitigation is encrypting the database password in Web.config.

How dangerous is this? Are we really planning such an astronomical phenomenon?

This mitigation has already proven its worth once: when the ASP.NET Oracle vulnerability was discovered. Anyone who stored the plaintext password in Web.config was at risk; anyone who encrypted the password was not. How confident are you that another similar vulnerability in ASP.NET will not be discovered in the next few years?

Should we also encrypt the source code and decrypt it at runtime? It seems excessive to me.

So what if an attacker gains access to your source code? What asset are you protecting and what threat are you bothering? I think in many cases the source code is much less valuable than the data. (I’m thinking here about ready-made commercial and open source software that anyone can get.) And if your source code is valuable, maybe obfuscation is something to think about.

I feel that they already have limited access to your mailbox, then your host failed or you already installed vulnerable services.

What about ASP.NET security vulnerabilities or your code? From time to time they appear.

I am worried about standard practice. Is this the standard?

Microsoft recommended encryption of connection strings.

What you need to do is evaluate the risk that saving the plaintext password is:

• How likely is it that an attacker can detect and exploit the security vulnerability that Web.config provides? Based on past history, I would say that the probability is low (but not "astronomically" low).
• How valuable is your data? If all you keep is photos of your cat, then it may not matter if the attacker gets the password for your database. But if you store , then from a legal point of view, I would say that you should take all possible measures to protect your application, including encryption of connection strings.

Answer 2

I think that this is not from "external" protection, but from "inside".

Sometimes the SQL administrator / user and OS administrator are different people. But the OS administrator has access to all the files, so he can easily read the SQL credentials in the web.config file. But these credentials can be encrypted in such a way that even the OS administrator does not have the ability to decrypt.

And this is hardly "security through obscurity" because the encrypted connection string cannot be decrypted without the correct user certificate, and usually only the "IIS" user has this.

Answer 3

Note that if production passwords are present in the web.config file, any developer who has access to this file has access to the Production database. This is especially a problem when the username in the connection string has read / write access to the database. Then it becomes possible for developers to “fix” things without recording that a “correction” has ever occurred.

Answer 4

I read some articles on the IHackStuff online blog. This guy explained some ways to get really interesting information using the Google search engine typing things in the search box, for example:

filetype:config web.config -CVS 

This came out with several results related to cached web.config files on production servers, and all information about these files was available to the public. Given this possibility, I would still recommend encrypting access information to the web.config database whenever such information is valuable enough.

Answer 5

You are correct that web.config will not be served by ASP.NET in the browser. But the developers are careful, therefore, when releasing a new version, sometimes they copy the well-known good web.config to something like web.config.old or web.config.bak. And since the developers are lazy, after the release they forget to delete the old web.config or keep it hanging for several days if they need to cancel the release.

Now the browser will display the .old and .bak files, which means that it is easy to write a script or tool that scans these files and downloads them to an attacker, who can then go through them leisurely to look for connection strings with usernames and passwords, and all of a sudden, credit card numbers from your database are being distributed online ...

If you don't want to get into the command lines and RSA keys (and, frankly, why do you need it?), Check out this tool to encrypt your web.config.