如何保护 Windows .net 应用程序中的静态字符串？
我们正准备部署一个 Windows .NET 客户端应用程序，它将向我们的中央服务器发出 Web 服务调用。我们需要验证对 Web 服务的所有调用均来自我们的客户端应用程序，而不是来自任何其他调用者。有人建议我们传递一个对我们的应用程序的所有安装都通用的安全令牌。但是，我们现在可以在应用程序安装中保护这个通用字符串。有没有一种有效的方法可以合理地保护这样的字符串不被黑客发现？
感谢您的任何建议。
We are preparing to deploy a Windows .NET client app that will make web service calls back to our central server. We've been given the requirement to validate that all calls made to the web service come from our client apps and not from any other caller. It's been proposed that we pass along a security token that is common to all installations of our application. However we now have this common string to secure within the application installation. Is there an effective way to reasonably protect such a string from being discovered by a hacker?
Thanks for any and all advice.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
SecureString处理令牌。这样从内存中检索令牌就会变得更加困难。app.config中，并加密“connectionStrings”部分。这样，令牌将受到除用户帐户（通过 DPAPI）之外的任何人的保护。SslStream进行客户端服务通信。这样，您的连接将被加密。与令牌相结合，您的通信现在将经过身份验证（即您了解您的客户）并受到保护。SecureStringto deal with the token at all times. This way it will be a lot harder to retrieve the token from the memory.app.configand encrypt the 'connectionStrings' section. This way the token will be secured from anyone except the user's account (through DPAPI).SslStreamto do the client-service communications. This way, your connection will be both encrypted. Coupled with the token, your communications will now be both authenticated (i.e. you know your client) and secured.WCF 服务中的身份验证和授权 - 第 1 部分
Authentication and Authorization in WCF Services - Part 1
这称为公钥加密。
如果黑客知道二进制文件中的前缀，它将不知道服务器提供的后缀，并且无法解密您发送回服务器的内容，因为黑客没有服务器私钥。漏洞是黑客可以提取应用程序中的私钥来解密后缀。但如果需要，服务器可以每隔几秒更改一次，或者它可以与时间相关。然而，可以利用时间相关性，如果您选择此选项，最好更改可变的时间相关后缀。在某些时候，经过大量的努力和一台可用的超级计算机，黑客也可以通过搜索可以解密所有发回的结果字符串的密钥来破解它，这就是为什么您不应该在服务器，但回收其中很少。
如果您认为这工作量太大，您可以使用 SecureString 和加密的连接字符串。但这肯定是可以利用一些时间来破解的，因为所需的一切都在客户端，并且黑客不需要 x*2 暴力解密。
It's called public key encryption.
If the hacker knows your prefix that is in your binary file it wont know the suffix that the server provides, and wont be able to decrypt what you send back to the server because the hacker doesn't have the servers private key. Vulnerability is that the hacker could extract the private key in the app to decrypt the suffix. But the server can change that every few seconds if required or it can be timedependent. However time dependent can be exploited, it is better to have a variable time dependent suffix change if you choose this. At some point and with a lot of effort and a supercomputer at disposal the hacker could hack that too, by searching for a key that can decrypt all of the resulting strings that are sent back, that is why you should not generate random suffixes on the server but recycle few of them.
If you think that is too much work, you could use SecureString and encrypted connection strings. But that sure is hackable with some time at disposal because everything needed is on client side, and the hacker does not need x*2 bruteforce decrypt-ions..