我不会说在Web中存储明文密码.config本身就是一个安全漏洞。但是，加密密码 是一种有用的纵深防御措施，而不仅仅是通过隐秘的安全性：

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. 如果IIS配置错误以服务Web.config？


2. 如果在ASP.NET中发现了安全漏洞（例如 padding oracle漏洞）允许任何人下载Web.config？


3. 不同程度从完整的管理特权到服务器端代码注入，对Web服务器的访问权限。如果攻击者只能设法完成后者，则他可能能够读取Web.config，但可能无法访问机器密钥，特别是如果您的应用程序在部分信任下运行。

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.

最后，由您决定是否可以接受将纯文本密码存储在Web.config中的风险。当然，如果可以选择Windows身份验证，那么您可能要考虑使用它而不是SQL身份验证。

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.

更新：安全性，***识别资产 和威胁 。在这种情况下，资产是数据库中的敏感数据（如果数据不重要，那么为什么还要用密码保护它呢？），威胁是攻击者有可能以某种方式获得对Web.config的访问权，从而访问数据库也一样缓解的一种可能是在Web.config中加密数据库密码。

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?

这种缓解措施已经证明了它的价值：ASP.NET发现padding oracle漏洞。在Web.config中存储明文密码的任何人都有危险；没有加密密码的人。您如何确定在未来几年内不会发现ASP.NET中的另一个类似漏洞？

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.

ASP.NET或您的代码中的安全漏洞如何？它们会不时弹出。

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 建议加密连接字符串。

Microsoft has recommended encrypting connection strings.

您应该做的是评估存储明文密码的风险构成：

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

• 攻击者发现并利用暴露Web.config的安全漏洞的可能性有多大？根据过去的历史，我想说可能性很小（但不是天文学上很低）。


• 您的数据有多有价值或有多敏感？如果您所存储的只是猫的照片，那么攻击者是否获得您的数据库密码可能并不重要。但是，如果您要存储个人身份信息，那么从法律的角度来看，我会说你应该采取所有可能的措施来保护您的应用程序安全，包括对连接字符串进行加密。

• 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.