【问题标题】:Protecting connection string from Man in the middle保护连接字符串免受中间人的伤害
【发布时间】:2010-11-07 13:46:35
【问题描述】:

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

但这里有几个问题。

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

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

【问题讨论】:

    标签: sql-server winforms connection-string sqlconnection


    【解决方案1】:

    您无法保护连接字符串。您可以通过 SSL 安全通道进行连接。

    【讨论】:

      【解决方案2】:

      在保证连接字符串安全方面,您只有有限的方法。

      一个选项,如果您的连接字符串存储在 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 窗体应用程序提供一个 URL,它可以通过该 URL 访问 Web 服务,但是通过仅允许使用用户特定的用户名/密码组合进行访问,该 Web 服务的使用将受到限制和控制。

      这样,您可以在物理上托管 Web 服务(不必是 web service - 它可以是您的 Windows 窗体的应用程序将通过 .NET remotingWCF 与之通信的远程应用程序)您确实可以完全控制并使用perimeter security保护这台机器的独立服务器/机器。

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

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

      只要将连接字符串放在用户的机器上,即使处于加密状态,您也需要赋予同一台机器解密该加密连接字符串的能力,并且链中存在薄弱环节和点在那里(对于足智多谋的用户)可以确定您的纯文本连接字符串。您可以将加密连接字符串的解密卸载到另一台(安全)机器,但这只是前面提到的客户端-服务器机制的一种变体,其中执行保持安全的部分(解密密钥、连接字符串等)在您自己的安全控制下的另一台机器上。

      【讨论】:

      • "但随后此 Web 服务的使用将受到限制和控制,仅允许使用用户特定的用户名/密码组合进行访问。"...鸡和蛋的问题,不是吗?...您现在需要隐藏用户名/密码
      • @BlackTigerX - 我明白你在说什么,但没有理由需要在应用程序中硬编码与 web 服务一起使用的用户名/密码组合(就像连接字符串需要到某个地方),但可以绑定到手动身份验证机制,用户必须在运行时提供凭据(例如登录到 Windows)。
      【解决方案3】:

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

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

      这一篇描述了 SQL 身份验证(用于 ASP.NET):

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

      看来你真的只需要加密用户名和密码?在这种情况下,Windows 身份验证应该是一个选项(尽管我经常无法让它为我工作)

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 2012-11-17
        • 2016-10-27
        • 1970-01-01
        • 1970-01-01
        • 2012-02-06
        • 1970-01-01
        • 2011-03-31
        • 2018-11-15
        相关资源
        最近更新 更多