在中间保护Man的连接字符串

时间:2009-07-02 08:32:44

标签: sql-server winforms connection-string sqlconnection

在我的winforms应用程序中,我正在对本地级别的连接字符串进行哈希处理。

但这里有几个问题。

我的应用程序解密连接字符串后,连接字符串信息以明文形式发送?由于我的应用程序是在本地安装的,因此中间人可能是任何用户?

我如何保护连接字符串,因为“强制加密”选项需要额外的证书?

3 个答案:

答案 0 :(得分:7)

此处只有有限的方法可以确保您的连接字符串安全无虞。

一种选择,如果您的连接字符串存储在web.config或app.config文件中(分别用于Web和Windows应用程序),您可以加密该值。这里有几个链接,详细说明了如何做到这一点:

Encrypting Web.Config Values in ASP.NET 2.0

Encrypt Connection Strings in VS 2005 .config Files

当然,正如你说的那样,这可能无法达到你想要的安全性,因为应用程序很可能在用户的机器上运行,因此app.config文件(即使在加密状态下)也可以运行加密/解密密钥也可以在用户的​​机器上使用。然后,知识渊博且有进取心的用户可以访问您的“纯文本”连接字符串。

恕我直言,防止用户看到您的数据库连接字符串的最佳方法之一就是永远不要将它们提供给他们,加密与否。这将要求您的Windows窗体应用程序不直接与数据库对话(使用连接字符串),而是直接与(例如)Web服务对话。

当然,您可以为Windows窗体应用程序提供一个可以访问Web服务的URL,但是这个Web服务的使用将受到限制和控制,只允许使用用户特定的用户名/密码组合进行访问。

这样,您可以托管Web服务(不必是web service - 它可以是您的Windows窗体应用程序将通过.NET remoting或{{3}进行通信的远程应用程序}}}在物理上独立的服务器/机器上,您执行可以使用WCF完全控制并保护此计算机。

您在此安全计算机上运行的应用程序和服务可以访问数据库的连接字符串,并且此连接字符串不需要在本机的外围泄露,从而保证其完全安全(假设上述周边安全措施到位且有效)。

当然,实现所有这些几乎肯定意味着对应用程序进行了巨大的体系结构更改,这取决于应用程序的大小和性质,可能是也可能不值得,但是,真正保护连接的唯一方法来自用户(或用户的机器)的字符串是为了确保它永远不会(以加密或解密的形式)提供给用户(或用户的机器)。

只要您将连接字符串放在用户的计算机上,即使处于加密状态,您也需要为同一台计算机提供解密该加密连接字符串的能力,并且链中存在弱链接和点在哪个(对资源丰富的用户)可以确定您的纯文本连接字符串。您可以将加密连接字符串的解密卸载到另一台(安全)计算机,但这只是前面提到的客户端 - 服务器机制的一种变体,从而执行保持安全的部分(解密密钥,连接字符串等)在您自己的安全控制下的另一台机器上。

答案 1 :(得分:4)

您无法保护连接字符串。你可以做的是通过SSL安全通道连接。

答案 2 :(得分:0)

MSDN中的此页面描述了如何为连接实现SSL:

http://support.microsoft.com/kb/316898

这个描述了SQL身份验证(对于ASP.NET):

http://msdn.microsoft.com/en-us/library/ff648340.aspx

您似乎只需要加密用户名和密码?在这种情况下,Windows身份验证应该是一个选项(虽然我经常遇到问题让它为我工作)