Question

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

Of course people say this could be a vulnerability as you are storing password in plaintext.

However, from what I know, IIS never serves web.config, and web.config should only have read access to administrators and IIS anyway. So if the hacker has gained access to the webserver, then it won’t matter what encryption I use because the private key will be on the webserver.

Wouldn’t encrypting connection string be classified as security through obfuscation?

Is it worth encrypting web.config connection string and storing the private key on the webserver?

Further, of course if I don’t use SSL, I am transmitting connection string over HTTP in plaintext. If I use SSL then this problem should be mitigated as well.

Answer 1

I wouldn’t say that storing a plaintext password in Web.config is a security vulnerability, in and of itself. But encrypting the password is a useful defense-in-depth measure, not just security through obscurity:

1. What if IIS is misconfigured to serve Web.config?
2. What if a security vulnerability is discovered in ASP.NET (like the padding oracle vulnerability) that allows anyone to download Web.config?
3. There are varying degrees of access to the Web server, from full administrative privileges to server-side code injection. If an attacker can only manage to do the latter, he might be able to read Web.config but might not be able to access the machine keys, especially if your application is running under partial trust.

In the end, it’s up to you to decide if the risk of storing plaintext passwords in Web.config is acceptable. Of course, if Windows authentication is an option, then you may want to consider using that instead of SQL authentication.

UPDATE: When talking about security, it’s a good idea to identify the assets and the threats. In this case, the asset is sensitive data in the database (if the data is unimportant, then why bother protecting it with a password?), and the threat is the possibility of an attacker somehow gaining access to Web.config and thus the database as well. A possible mitigation is to encrypt the database password in Web.config.

How much of a risk is it? Do we really have to plan for such an astronomically rare occurrence?

This mitigation has already proved its worth once: when the ASP.NET padding oracle vulnerability was discovered. Anyone who stored a plaintext password in Web.config was at risk; anyone who encrypted the password wasn’t. How certain are you that another similar vulnerability in ASP.NET won’t be discovered in the next few years?

Should we also encrypt source code and decrypt on run-time? Seems excessive to me.

So what if an attacker does get access to your source code? What’s the asset you’re protecting, and what’s the threat you’re concerned about? I think that in many cases, source code is much less valuable than data. (I’m thinking here about off-the-shelf commercial and open-source software which anyone can obtain.) And if your source code is valuable, maybe obfuscation is something to think about.

I feel if they already have even limited access to your box, then your host has failed or you’ve installed vulnerable services already.

What about security vulnerabilities in ASP.NET or your code? They do pop up from time to time.

My concern is standard practices. Is it a standard?

Microsoft has recommended encrypting connection strings.

What you should do is evaluate the risk that storing a plaintext password poses:

• How likely is it that an attacker will be able to discover and exploit a security vulnerability that exposes Web.config? Based on past history, I’d say the likelihood is low (but not “astronomically” low).
• How valuable or sensitive is your data? If all you’re storing is pictures of your cat, then maybe it doesn’t matter much whether an attacker gets your database password. But if you’re storing personally identifiable information, then from a legal standpoint, I’d say you should take all possible measures to secure your application, including encrypting your connection strings.