不想在移动设备、设计模式上存储秘密的 Facebook/Twitter API 密钥？
我有一个问题，就是让我的秘密 API 密钥存在于世界各地潜在的数千台移动设备上。它很容易被黑客破坏并用于恶意目的。
那么我有哪些选择呢？ 我猜想一个私人服务器拥有秘密 API 密钥和一个封装所有方法调用的 Web 服务。因此，移动设备不必拥有密钥并执行以下操作：列出<朋友> = service.GetFriends(secretKey);
如果我的秘密 API 密钥被泄露并用于垃圾邮件/滥用目的，我必须关闭所有用户的使用，让我的应用程序死在大海中。
所以我的想法是我可以使用移动设备唯一的设备 ID 并执行以下操作：列出<朋友> = myService.GetFriends(deviceID);
当然，恶意黑客可以使用虚假的 deviceID 调用我的 Web 服务，但至少我现在可以控制将 deviceID 列入黑名单。它还引入了一些潜在的带宽问题，但这是一个不太值得关注的问题。
真正的 PKI 可能是不可能的，因为目标设备在当前版本中不处理 HTTP 客户端证书。
还有其他好主意吗？
I have an issue with letting my secret API key be all over the world on potentially thousands of mobile devices. It could easily be compromised and used for malicious purposes by a hacker.
So what are the options for me?
I would guess a private server which has the secret API key and a web service that encapsulates all method calls. So instead of the mobile device having the secret key and does something like:List<Friends> = service.GetFriends(secretKey);
If my secret API key is compromised and is used for spamming/abuse purposes, I must shut down the use for all my users, leaving my application dead in the sea.
So my idea is that I can use the mobile device unique device ID and do:List<Friends> = myService.GetFriends(deviceID);
Of course, a malicious hacker could just call my web service with a fake deviceID, but at least I now have control to blacklist deviceID's. It also introduces some potential bandwidth isssue, but that is of a less concern.
A true PKI is probably out of the question, since the targetted device doesn't handle HTTP client certificates in the current version.
Any other good ideas?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您不想将 API 密钥发布到 Facebook 或 Twitter，即使在客户端中进行了混淆。
您的直觉是正确的，可以通过您控制的服务进行代理。限制对该服务的访问取决于您 - 未经授权的使用风险有多大？设备 ID 是设备/用户身份的一个很好的线索，但可以伪造。
您可以使用更强大的身份验证方法（短信身份验证等）来建立长期会话或设备密钥，但是这些方法更加复杂，并且会给最终用户带来更高的负担。
TL;DR
保护您的平台 API 密钥。确保您自己的 API 足以满足您的需求。
You don't want to publish your API key to Facebook or Twitter, even obfuscated within a client.
Your instincts are correct to proxy through a service you control. Limiting access to that service is up to you - how much risk is unauthorized use? Device ID is a pretty good clue to device/user identity, but can be faked.
There are stronger authentication methods you could use (SMS auth, etc) to establish a long-term session or device key, however these are more complex and impose a higher burden on the end user.
TL;DR
Protect your platform API keys. Secure your own API enough to protect your needs.