我做了以下假设:
a)我无法在托管内存之外实例化SqlConnection对象
b)托管内存中的任何字符串都可以被诸如Hawkeye这样的应用程序读取
你说得完全正确,SecureString在需要将字符串传递给托管API(例如设置ConnectionString)时并没有任何好处。
它真正设计用于与安全的非托管API进行安全通信。
微软理论上可以考虑增强SqlConnection对象以支持安全的ConnectionString,但我认为他们不太可能这样做,因为:
SecureString在客户端应用程序中才真正有用,例如从用户输入逐个字符构建密码而不会将整个密码存储在托管字符串中。
在这种环境下,更常见的是使用Windows身份验证连接到SQL Server。
在服务器上,保护SQL Server凭据的其他方法包括限制对服务器的访问权限仅授予授权管理员。
2012
微软加强了 SqlConection 对象的功能,通过将 SqlCredential 传递给新的 SqlConnection.Credential 属性来支持安全的 ConnectionString。
SecureString pwd = AzureVault.GetSecretStringSecure("ProcessPassword");
SqlCredential = new SqlCredential("Richard", pwd)
connection.Credential = cred;
很遗憾,没有其他DbConnection的后代支持它 (例如,OdbcConnection、OleDbConnection、OracleConnection、EntityConnection、DB2Connection)。
您可以并且应该使用SecureString来避免密码在内存中明文存在并暴露于攻击之下。而不是使用SQL连接字符串,您需要使用新的SqlCredential类,其中Password属性是SecureString。请参考以下文章以获取帮助。
https://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlcredential.password(v=vs.110).aspx
http://www.codeproject.com/Tips/408901/Storing-your-connection-string-password-in-SecureS
将SecureString值分配给SQLConnection.ConnectionString将绕过安全性,使其无用。
SecureString旨在解决这些普通字符串问题,ref:
在我看来,SecureString类型是一个修补程序,用于修复不良的安全实现,目前SecureString尚未在整个框架中实现,因此无法充分利用其优势。
我有同样的问题,我选择RSA加密将敏感信息存储在内存中。
另一种解决方案是通过数据库服务器上的服务托管数据访问层,该服务在本地系统帐户下运行,连接到数据库并提供数据,而本地用户将无法访问服务配置。