![]() |
1
6
你在本地储存的任何东西都可能被破坏。但是你可以采取一些措施来增加难度。上有一个文档 Handling Passwords 你可以考虑看看。您将熵密钥视为特定于应用程序的密码。 我要把你的熵称为 钥匙 ,因为它在功能上是一个附加密钥。 您不想做的是以未加密的格式在本地存储密钥。相反,您要么加密密钥,要么从另一个明显的源中派生密钥。当然,如果您加密密钥,那么您需要存储用于加密密钥的密钥—但通常情况下,这一层间接寻址足以阻止大多数挑战者。 这就是你拿到钥匙的好处。您可以将其派生为其他常量数据的散列(需要是不随应用程序的修订而更改的数据)。不过,在派生散列时,有一个技巧是将散列与其他常量值(如guid或大随机数)组合起来,这样其他人就不能将已知的散列算法组合起来并获取密钥。这是创建自己的散列算法的更好的选择(除非你有数学博士学位,否则永远不应该这样做)。 在某个时候,你需要在你的应用程序中硬编码某种密钥。这个密钥可以与散列中的一些其他数据组合以创建熵密钥,也可以用于解密熵密钥。实际上,只要保留用于解密现有密钥的旧密钥,就可以使用应用程序的新修订版更改密钥。然后可以用新的密钥或方法对其重新加密。 如果你想要最好的安全性,那么你可以把熵密钥存储在计算机上。这需要一个Internet连接和一个SSL证书,但是它们的密钥永远不会保存在本地任何地方以便被发现。为此,您可以设置一个更健壮的质询响应系统,以便每次的请求身份验证都是不同的,并且密钥通过ssl加密传递,因此不能被截获。一旦密钥被使用,它就会被丢弃。当然,这种情况会破坏使用dpapi进行本地安全存储的许多场景的目的。 不管你做什么,记住它都会被破坏——当有人完全访问本地机器和存储在它上的数据时,这种情况总是会发生的。解决这个问题的办法是不断地发布更新,这些更新足以改变方法,使旧的破解不再工作。这将使裂缝的分布不那么有价值,因为很难找到一个合适的版本。 |
![]() |
2
0
首先,让我来回答最初的问题。归根结底,如果熵要用于持久化存储,它必须存储在用户和/或应用程序的权限之下。我想您可以使用与应用程序一起存储的密钥来加密持久化存储中的信息,但恶意应用程序将能够再次访问此加密密钥。所以,我觉得没有什么方法可以避免你在评论中提到的情况。然而,考虑到你所说的是熵的预期用途,我觉得它对解决你的问题没有帮助。 听起来好像实际的问题是在客户端应用程序和服务器之间建立一个安全的通信通道。在您的设计中,您正在交换将用于加密通信的密钥。我认为尝试使用自定义代码来解决此问题将导致额外的安全漏洞。 考虑到这一切,我建议创建一个用于检索敏感信息的WCF(Windows Cuffic Foundation)服务。它显然可以用于检索所有信息,但最少的更改是将服务限制为敏感信息。 使用wcf,可以将客户端和服务器配置为使用安全通道。wcf有很多选择来建立到服务器的安全通信通道。
一旦你有了一个安全的通道,许多其他的问题就变得简单了,比如对cc数据的访问。如果该数据是通过安全通道发送的,则它将成为一个授权问题,而不是通道安全问题。 |