我很惊讶这个问题没有得到深入讨论：
This article告诉我们如何使用windbg在内存中转储正在运行的.Net进程字符串。
我花了很多时间研究SecureString类，它使用非托管固定内存块，并保持数据加密。好东西。
当您使用其值并将其分配给SQLConnection.ConnectionString属性（属于System.String类型）时，会出现此问题。这是什么意思？嗯......
这完全否定了SecureString功能！
最重要的是，SQLConnection类是无法使用的，我甚至无法使用SecureString属性自行滚动;耶和闭源。耶。
新的DAL层正在进行中，但是对于新的主要版本和对于这么多用户而言，每个用户升级之前至少需要2年，其他人可能无论出于何种原因无限期地保留旧版本。
由于使用连接的频率，从SecureString编组将无济于事，因为不可变的旧副本会粘在内存中，直到GC出现。集成Windows安全性不是一种选择，因为一些客户端不在域上工作，而其他客户端则通过网络漫游和连接。
如何在内存中保护连接字符串，以便使用windbg无法查看？
答案 0 :(得分：10)
如果您控制机器的程度可以读取另一个进程的内存，您还可以使用string的引用替换对SecureString类的引用。您可以访问其他进程可以使用的任何私钥。
对于拥有您的进程内存的黑客，没有任何防御措施。 ：）
答案 1 :(得分：4)
这个问题不是真正的答案，但仍然是：
尝试使用Windows身份验证而不是sql身份验证。即使您设法在程序存储器中保护密码，用户也可以使用流量嗅探器来查看密码。
Windows身份验证的另一个优点是sql server不需要存储用户的密码哈希值。使用sql身份验证确定黑客可以从哈希强制密码或用另一个替换它。实际上，使用某些程序可以很容易地替换密码。
答案 2 :(得分：2)
进程和Sql Server之间的通信理想情况下发生在主干上，如果受到损害，那么这是您最不担心的问题。
答案 3 :(得分：1)
由于它是一个客户端桌面应用程序，如果您想知道您的连接字符串凭据可能会暴露给某些黑客，这是一个设计缺陷......
如果使用管理员凭据连接到sql server，则这是您的问题。您应该创建一个具有限制的用户并在您的应用中使用它。
如果您害怕公开数据库，可以从应用程序访问Web服务。然后，此Web服务将访问数据库并返回结果。