所以我使用SQL身份验证使用我的web.config连接字符串。
当然，有人说这可能是因为你是明文存储的密码中的漏洞。
不过，据我所知，从来没有IIS服务的web.config，和web.config中应该只具有读取权限管理员和IIS反正。 因此，如果黑客获得了访问Web服务器，那么它不会不管我用什么加密，因为私钥将在Web服务器。
不会加密的连接字符串被归类为通过模糊的安全？
是否值得加密web.config中的连接字符串和存储在Web服务器上的私有密钥？
此外，当然，如果我不使用SSL，我通过HTTP明文传输的连接字符串。 如果我使用SSL那么这个问题也应得到缓解。
我不会说，存储在Web.config中明文密码是一个安全漏洞，在其本身。 但是，加密密码是一个有用的防御纵深的措施，而不是仅仅通过隐藏的安全性：
最后，它是由你来决定，如果在Web.config中存储明文密码的风险是可以接受的。 当然，如果Windows身份验证是一个选项，那么你可能要考虑使用的是不是SQL身份验证。
更新：当谈到安全性，这是一个好主意，以确定资产和威胁 。 在这种情况下，该资产是敏感的数据库中的数据（如果数据是不重要的，又何苦用密码保护吗？），并威胁攻击者以某种方式获得访问Web.config文件的可能性，因此数据库为好。 一个可能的缓解措施是加密Web.config中的数据库密码。
如何危险的是多少呢？ 难道我们真的要规划这样一个天文数字般的罕见的发生？
这缓解已经证明了它的价值，一旦：在ASP.NET填充神谕漏洞被发现时。 任何人谁在Web.config中存储的明文密码有危险; 人谁加密的密码不是。 如何一定是你在ASP.NET另一个类似的漏洞将不会在未来几年内被发现的？
我们应该还加密代码和解密的运行时间？ 似乎是过分了我。
因此，如果一个攻击者做什么他都能看到你的源代码？ 什么是你要保护的资产，什么是你关心的威胁？ 我认为，在很多情况下，源代码是不是数据有价值得多。 （我想在这里大约关闭的，现成的商业和开源软件，任何人都可以获取。）如果你的源代码是有价值的，也许混淆是值得思考的问题。
我觉得，如果他们已经拥有了即使是有限的，以你的机器访问，那么你的主机出现故障，或者您已经安装了易受攻击的服务。
怎么样在ASP.NET中的安全漏洞或你的代码？ 他们会不时弹出的时间。
我担心的是标准的做法。 它是一个标准呢？
微软建议加密连接字符串。
你应该做的是评估风险，即存储明文密码会导致：
考虑到，如果密码生产中存在的web.config文件，然后可以访问该文件的任何开发人员访问生产数据库。 这尤其是一个问题，当在连接字符串中的用户名已经阅读到数据库/写访问。 其结果，可为开发人员没有记录，即“修复”“修复”的事情发生过。
我想，这是不是从“外部”的保护，但对于“内部”。
有时，SQL管理员/用户和操作系统管理员是不同的人。 但是，操作系统管理员可以访问所有文件，这样他就可以轻松地阅读在web.config文件中的SQL凭据。 但是，这些证书可以在某种程度上被加密，即使操作系统管理员也没有办法解密。
它几乎没有“通过隐藏的安全”，因为加密的连接字符串canno't不正确的用户证书进行解密和usualy只有IIS“用户”有一个。
我以前读IHackStuff网上博客的文章。 这家伙解释了一些方法来使用搜索框谷歌搜索引擎键入东西才能拿到真正有趣的信息，如：
filetype:config web.config -CVS
此推出了相关的缓存web.config文件中对生产服务器上的多个结果，这些文件的所有信息都提供给公众的视线。 考虑到这种可能性，我还是会建议更换，只要该信息是足够有价值的web.config文件进行加密的数据库访问信息。
你说得对， web.config不会被ASP.NET送达给浏览器。 而开发商则是谨慎的，因此，当他们发布一个新版本，有时他们已知良好的web.config文件复制到类似web.config.old或web.config.bak。 而且，由于开发商是懒惰，上映后却忘记删除旧的web.config文件，或把它挂轮的情况下，过几天他们需要回滚的版本。
现在，名.old和.bak文件将被提供给浏览器，这意味着它很容易编写一个脚本或扫描这些文件，并将它们下载到黑客那么谁可以通过他们去在他们的休闲，寻找连接的工具从你的数据库用户名和密码，突然信用卡号码串在网上流传...
如果你不想要进入的命令行和RSA密钥（坦白地说，为什么你会吗？），看看这个工具加密你的web.config。
