需要安全地存储和传输密钥
我面临的问题是一个有趣的问题，我的安全知识很强，但我的理解很弱。也就是说，我了解该理论，但在这方面几乎没有实际应用。我存储了密码，使用盐传输它们，验证了它们的哈希值，等等。我的需求相似但具体。
我有一个应用程序，其他外部应用程序可以通过 ContentProvider URI“挂钩”。外部应用程序可以由任何人开发，因此我无法控制它们。但是，我想限制订阅者的某些访问权限。为了促进这一点，每个“订阅的”应用程序都将有一个注册到其包名称的密钥。然后 ContentProvider 需要验证该密钥是否有效。
我的问题是这样的： 由于它是通过 URI 传递的，因此很容易拦截传输中的密钥。此外，我的订阅者需要一种方法来存储自己的密钥，而无需连接到安全服务器。当然，他们不能将密钥作为文字存储在应用程序中，因为这很容易导致漏洞。我试图提供尽可能多的解决方案，而不必“信任”这些其他应用程序的安全性。
那么，我们如何在我的数据库及其外部应用程序中存储密钥，并允许他们将其发送给我以进行专门验证的查询？我认为我理解如何做到这一点的问题是持久存储的方面以及它如何影响模型。也就是说，对于密码模型，密码是被键入的并且通常不被存储。
模糊逻辑
The issue I am facing is an interesting one and my knowledge of security is strong, but my understanding is weak. That is, I understand the theory, but have had little practical application in this particular regard. I have stored passwords, transmitted them using salt, verified them a hash, etc. My needs here are similar but specific.
I have one application that other external application may "hook" into via a ContentProvider URI. External applications may be developed by anyone, thus I do not have control over them. However, I want to limit some access to subscribers. To facilitate this, each "subscribed" application will have a key registered to its package name. The ContentProvider then needs to verify this key as valid.
My issue is this:
Since it is passed via URI, it is easily possible to intercept the key in transit. Additionally, my subscribers need a method by which they can store their own key without having to connect to a secure server. They cannot store the key as a literal within their app, of course, as this makes for easy vulnerability. I am trying to provide as much of a solution as possible without having to "trust" the security of these other applications.
So, how do we store a key in both my database and their external application, and allow them to send it to me for specifically verified queries? I think my issue in understanding how to do this is the aspect of persistent storage and how it affects the model. That is, with a password model, the password is typed and not typically stored.
FuzzicalLogic
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
处理加密质询/响应中的密钥。
客户端请求使用预先确定的每个应用程序公钥加密的质询值。
如果客户端随后将使用客户端特定服务器的公钥加密的正确值返回给服务器，则握手成功。
使用每个应用程序的私钥/公钥以及诸如挑战值的引导之类的东西，将很难复制。
除非最初注册应用程序开发人员，否则密钥永远不会易手。
Process the key in an encrypted challenge / response.
Client requests challenge value encrypted with a predetermined per application public key.
If the client then returns the correct value to the server encrypted using the client specific server's public key then the handshake was a success.
Using a per application private key / public key and something like a guid for challenge value, it would be very hard to duplicate.
and the keys never change hands except when registering the application developer initially.