保护连接字符串免受中间人的影响
在我的 winforms 应用程序中，我正在本地级别对连接字符串进行哈希处理。
但这里有几个问题。
我的应用程序解密连接字符串后，连接字符串信息以明文形式发送？ 由于我的应用程序是本地安装的，中间的人可能是任何用户？
除了需要额外证书的“强制加密”选项之外，我如何保护连接字符串？
In my winforms application i am hashing the connection string in local level.
But here a couple of questions.
After my app decrypts the connection string, the connection string info is sent in clear text? And since my app is installed locally the man in the middle could be ANY user?
How can i protect the connection string, becides the "force encryption" option, which requires an extra certificate?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
为了保证连接字符串的安全，您在这里只有有限的方法。
一种选择是，如果您的连接字符串存储在 web.config 或 app.config 文件（分别适用于 Web 和 Windows 应用程序）中，您可以加密该值。 以下是详细说明如何完成此操作的几个链接：
加密ASP.NET 2.0 中的 Web.Config 值
加密 VS 中的连接字符串2005 .config 文件
当然，正如您所说，这可能无法实现您想要的安全性，因为应用程序很可能在用户的计算机上运行，因此 app.config 文件（即使在加密状态）和相关的加密/解密密钥也将在用户的计算机上可用。 然后，知识渊博且有进取心的用户就可以访问您的“纯文本”连接字符串。
恕我直言，防止用户看到数据库连接字符串的最佳方法之一就是从一开始就不要将其提供给他们，无论是否加密。 这将要求您的 Windows 窗体应用程序不直接与数据库对话（使用连接字符串），而是直接与（例如）Web 服务对话。
当然，您可以为 Windows 窗体应用程序提供一个可以访问 Web 服务的 URL，但是此 Web 服务的使用将受到限制和控制，仅允许使用用户特定的用户名/密码组合进行访问。
这样，您就可以托管 Web 服务（不必是 web服务 - 它可能是一个远程应用程序，您的 Windows 窗体应用程序将通过 .NET 远程处理 或 WCF ）在物理上独立的服务器/机器上，您确实可以通过周边安全。
您在这台安全计算机上运行的应用程序和服务可以访问数据库的连接字符串，并且该连接字符串永远不需要泄露到该计算机的边界之外，从而保持其完全安全（假设上述边界安全措施到位且有效）。
当然，实现所有这些几乎肯定意味着对应用程序进行巨大的架构更改，这取决于应用程序的大小和性质，可能值得也可能不值得，但是，真正保护连接字符串免受攻击的唯一方法是用户（或用户的计算机）的目的是确保用户（或用户的计算机）永远无法（以加密或解密的形式）使用它。
一旦您将连接字符串放在用户的计算机上，即使处于加密状态，您也需要为同一台计算机提供解密该加密连接字符串的能力，并且链中存在薄弱环节以及（对于足智多谋的用户来说）可以确定您的纯文本连接字符串。 您可以将加密连接字符串的解密卸载到另一台（安全）计算机，但这只是前面提到的客户端-服务器机制的一种变体，其中保持安全的部分（解密密钥、连接字符串等）是在在您自己的安全控制下的另一台机器上。
You have only a limited amount of approaches here with regard to keeping your connection string safe and secure.
One option, if your connection string is stored within a web.config or app.config file (for web and windows apps, respectively) you can encrypt the value. Here's a couple of links that detail how that can be done:
Encrypting Web.Config Values in ASP.NET 2.0
Encrypt Connection Strings in VS 2005 .config Files
Of course, as you quite rightly say, this may not achieve the security that you desire, since the application may well be running on the user's machine, and thus the app.config file (even in an encrypted state) and associated encryption/decryption keys will also be available on the user's machine. A knowledgeable and enterprising user could then gain access to your "plain-text" connection string.
IMHO, one of the best ways to prevent your users from seeing your database connection string is to never give it to them in the first place, encrypted or not. This would require that your windows forms application does not talk directly to a database (using a connection string), but rather would talk directly to (eg) a web service.
Of course, you'd give the windows form application a URL with which it could access the web service, but then usage of this web service would be restricted and controlled by only allowing access with a user specific username/password combination.
This way, you can host the web service (doesn't have to be a web service - it could be a remote application that your windows form's application would communicate with over .NET remoting or WCF) on a physically separate server/machine that you do have complete control over and protect this machine with perimeter security.
It would be the applications and services that you have running on this secure machine that have access to the database's connection string, and this connection string need never be divulged outside of the perimeter of this machine, thereby keeping it completely secure (assuming the aforementioned perimeter security is in place and is effective).
Of course, implementing all of this would almost certainly mean huge architectural changes to your application, which, depending upon the size and nature of your application, may or may not be worthwhile, however, the only way to truly secure your connection string from a user (or a user's machine) is to ensure that it is never available (in encrypted or decrypted form) to the user (or user's machine).
As soon as you put the connection string on the user's machine, even in an encrypted state, you need to give that same machine that ability to decrypt that encrypted connection string, and there is the weak link in the chain and the point at which (to a resourceful user) your plain-text connection string can be determined. You could off-load the decryption of the encrypted connection string to another (secure) machine, but that's just a variation of the previously mentioned client-server mechanism whereby the part that is kept secure (decryption key, connection string etc.) is performed on a different machine under your own secure control.
您无法保护连接字符串。 您可以做的是通过 SSL 安全通道进行连接。
you can't protect the connection string. what you can do is connect via SSL secure channel.
MSDN 中的此页面介绍了如何为连接实施 SSL：
http://support.microsoft.com/kb /316898
这个描述了 SQL 身份验证（针对 ASP.NET）：
http://msdn.microsoft.com/en-us/library/ff648340.aspx
看来你真的只需要加密用户名和密码？ 在这种情况下，Windows 身份验证应该是一个选项（尽管我经常遇到让它为我工作的问题）
This page in the MSDN describes how to implement SSL for the connection:
http://support.microsoft.com/kb/316898
And this one describes SQL Authentication (for ASP.NET):
http://msdn.microsoft.com/en-us/library/ff648340.aspx
It seems that you only really need to encrypt the username and password? In which case, Windows Authentication should be an option (although I often have problems getting it to work for me)