使用 DPAPI 时安全存储可选熵
所以我尝试使用 DPAPI 存储对称密钥。一切都很好，但是如何处理熵呢？这个回答的问题这里确实没有提供足够的见解。这看起来像是一个滑坡——我可以使用机器商店来存储熵，但又是什么阻止了人们获得这一点呢？注意：我使用用户范围存储当前密钥。
所以我的问题是 - 使用 DPAPI 存储熵的最佳方法是什么？
So I am trying to store the symmetric key using DPAPI. All is well and great, but what to do with the entropy? This answered question here really doesn't provide enough insight. It seems like a slippery slope - I could use the machine store to store the entropy but then what prevents someone from getting at that as well? Note: I am storing the current key using the User Scope.
So my question is - what is the best way to store the entropy using DPAPI?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您在本地存储的任何内容都可能受到损害。但您可以采取一些措施来使其变得更加困难。您可以参考处理密码文档可以考虑看一下。您将熵密钥视为特定于您的应用程序的密码。
我将把您的熵称为您的密钥，因为它在功能上是一个附加密钥。
您不想做的是以未加密的格式在本地存储密钥。相反，您想要加密您的密钥，或者从另一个不明显的来源获取它。当然，如果您加密密钥，那么您需要存储用于加密它的密钥 - 但通常这种单层间接就足以阻止大多数挑战者。
这将是派生密钥的优势。您可以将其派生为其他一些常量数据的哈希值（必须是不随应用程序的修订而改变的内容）。不过，派生哈希值时的一个技巧是将哈希值与其他一些常量值（例如 GUID 或大随机数）组合起来，这样其他人就不能仅组合已知的哈希算法并获取您的密钥。这是创建您自己的哈希算法（您不应该这样做，除非您拥有数学博士学位）的更好替代方案。
在某些时候，您将需要在应用程序中进行某种硬编码的密钥。该密钥可以与散列中的一些其他数据组合以创建熵密钥，或者用于解密熵密钥。实际上，只要保留旧密钥来解密现有密钥，您就可以使用应用程序的新版本来更改密钥。然后您可以使用新的密钥或方法重新加密它。
如果您想要最好的安全性，那么您可以将熵密钥存储在计算机之外。这需要互联网连接和 SSL 证书，但它们的密钥永远不会保留在本地任何地方以供发现。为此，您可以设置更强大的质询响应系统，以便每次请求身份验证都不同，并且密钥通过 SSL 加密传递，因此无法被拦截。一旦密钥被使用，它就会被丢弃。当然，这违背了许多使用 DPAPI 进行本地安全存储的场景的目的。
无论您做什么，请记住它都会受到损害 - 当有人完全访问本地计算机及其上存储的数据时，这种情况总是会发生。解决方案是不断发布更新，对方法进行足够的更改，使旧的破解不再起作用。这将使破解的分发价值降低，因为很难找到合适的版本。
Anything you store locally can be compromised. But there are steps you can take to make it more difficult. There is a document on Handling Passwords that you may consider looking over. You consider your Entropy Key a password specific to your application.
I am going to refer to your Entropy as your Key, since it is functionally an additional key.
What you don't want to do is store your key locally in an unencrypted format. Instead you want to either encrypt your key, or derive it from another, in-obvious source. Of course if your encrypt the key, then you need to store the key used to encrypt it - but often times this single layer of indirection is enough to discourage most challengers.
That would be the advantage of deriving your key. You could derive it as a hash of some other piece of constant data (needs to be something that doesn't change with revisions of your application). One trick when deriving a hash though is to combine the hash with some other constant value (like a GUID or large random number) so that someone else cannot just combine a known hash algorithm and get your key. This is a much better alternative to creating your own hash algorithm (which you should never do, unless you have a PHD in Mathematics).
At some point your are going to need some sort of key hard coded in your application. This key is either combined with some other data in a hash to create your Entropy Key, or used to decrypt the entropy key. You actually can have the key change with a new revision of your application, as long as you keep the old key for decrypting the existing key. Then you can re-encrypt it with the new key or method.
If you want the best security then you can store the Entropy key off the computer. This would require an internet connection and an SSL certificate, but then they key is never persisted anywhere locally to be discovered. To do this you can setup a more robust challenge response system so the request authentication is different each time, and the key is delivered over SSL encryption so it cannot be intercepted. Once the key is used, then it is discarded. Of course this kind of defeats the purpose of many scenarios where you are using DPAPI for local secure storage.
Whatever you do, keep in mind it will be compromised - that always happens when someone has full access to the local machine and the data stored on it. The solution to that is to keep releasing updates that change the method enough that the old crack no longer works. This will make distribution of a crack less valuable as it will be difficult to find one for the right version.
首先，让我解决原始帖子的问题。归根结底，如果熵要用于持久存储，则必须在用户和/或应用程序的权限下存储熵。我想您可以使用与应用程序一起存储的密钥来加密持久存储中的信息，但恶意应用程序将能够访问此加密密钥。因此，我认为没有办法防止您在评论中提到的情况。然而，考虑到你所说的是熵的预期用途，我认为它对解决你的问题没有帮助。
听起来好像实际的问题是在客户端应用程序和服务器之间建立安全的通信通道。在您的设计中，您正在交换将用于加密通信的密钥。我认为尝试使用自定义代码来解决此问题将导致额外的安全漏洞。
鉴于所有这些，我建议创建一个用于检索敏感信息的 WCF（Windows Communication Foundation）服务。显然，它可以用于检索所有信息，但最少的更改是将服务限制为敏感信息。
使用 WCF，您可以将客户端和服务器配置为使用安全通道。 WCF 有很多选项可用于建立与服务器的安全通信通道。
一旦有了安全通道，许多其他问题就会变得更简单，例如访问 CC 数据。如果该数据通过安全通道发送，那么这就变成了授权问题，而不是通道安全问题。
有关详细信息，请参阅如何：创建安全会话。
First, let me address the original post question. It boils down to the fact that the entropy must be stored under the authority of the user and/or the authority of the application if it is going to be used for persisted storage. I suppose you could use a key stored with the application to encrypt the information in the persisted store but again a malicious application would be able to access this encryption key. So, I do not feel there is a means to protect against the scenario you mention in comments. However, given what you have said is the intended use of the entropy, I do not feel it helps in solving your problem.
It sounds as if the actual problem is establishing a secure channel of communication between your client application and the server. In your design, you are exchanging keys that will be used to encrypt communication. I think that trying to use custom code to solve this issue will lead to additional security vulnerabilities.
Given all of that, I would suggest creating a WCF (Windows Communication Foundation) service that is used to retrieve sensitive information. It could obviously be used to retrieve all information, but the least amount of change would be to confine the service to sensitive information.
With WCF, you can configure both the client and the server to use a secure channel. WCF has plenty of options for establishing a secure channel of communication to the server.
Once you have a secure channel, many of the other problems are simpler such as access to the CC data. If that data is sent down a secure channel, it becomes an issue of authorization instead of channel security.
See How to: Create a Secure Session for more.