在网络配置中设置连接字符串是否是一种好习惯？

最近，我在工作中与一些同事进行了讨论，因为他们说最好在.DLL中加密一个字符串连接。我说过为什么不使用加密的web.config中定义的字符串连接？一样，更好，因为实体框架（例如，在应用程序的Web配置中查找连接的名称），现在，我想从安全角度了解哪种更好，什么是最佳实践？

没有实质性的区别，除了如果您想要将配置文件放入DLL中进行配置更改，则必须实际构建二进制文件，而管理员可以使用易于理解的现成工具来修改配置文件如果在配置中。MSDN上已经存在一种用于加密配置字符串的机制和其他指南。当前版本的Asp.Net可能具有其他机制，因此在采用这种方法之前，请做一些其他研究。

仅仅因为某些东西位于DLL中，并不能使其变得更加安全。文本编辑器也可以打开二进制文件，如Reflector之类的工具可以为浏览.Net DLL提供更好的界面。DLL将不提供任何“额外”加密。

没关系，其中加密的数据存储，它的问题是如何是加密的。

在web.config中加密的部分通常与加密数据保护API，这是极其到裂纹难以不损害整个机器。您也可以使用类似的RSA密钥容器（很难将其从计算机中取出）。

我想，如果您想将加密的字符串存储在DLL中，那虽然没本质上比加密的web.config（任何人都可以使用Reflector窥视该DLL ）更安全，但显然很难更改（您可以需要重新编译）。但是，更重要的是该加密字符串的生成方式。大概您没有使用与加密的web.config相同的提供程序，那么您使用的是什么？

加密方案仅与私钥或共享机密一样强。如果该密钥也存储在程序集中，那么您也可能根本没有加密。如果将其存储在某个外部数据库中，则会引发有关如何保护该数据库的连接字符串的问题。这实际上只会导致整体安全性下降。

另一方面，如果您是服务提供商，并且使用用户密码对连接字符串进行了加密，那么这将比使用静态机器密钥更安全。再说一次，如果您使用用户密码进行加密，则几乎不可能对程序集中的加密数据进行硬编码，因为需要响应用户（而非开发人员）的操作来生成和存储加密数据。

真的我想不出太多情况，在DLL中对（加密的）连接字符串进行硬编码比对相关的web.config部分进行加密更安全。充其量只是给您带来不便，最糟糕的是它依赖于一些笨拙的自定义安全性，其中充斥着漏洞。请帮自己一个忙，并按照Microsoft的建议执行操作-如果其中包含敏感数据，则只需加密web.config。

ASP.NET的最佳做法是将所有配置/设置都放在web.config文件或app.config文件中（对于其他项目类型）。

关于加密以及在连接字符串上使用加密的原因必须是非常特殊的情况。因为大多数情况下，高达99％的情况都不需要加密连接字符串。Microsoft自己的企业应用程序的连接字符串显示在web.config / app.config文件中。我认为您已经使安全复杂化了。

还有一件事，对连接字符串进行硬编码是不好的做法。例如，不要在DLL或.aspx / .ascx / .cshtml或代码隐藏中放置任何连接字符串（也称为connectionstring）。