作为 iPhone 应用程序一部分保护 API 凭据的最佳实践
我构建的应用程序经常有“社交媒体服务”要求；例如
- bit.ly
对于大多数此类服务，我需要拥有某种 API 密钥。我正在尝试找出将这些 API 密钥包含在应用程序二进制文件中的最佳方法。所需的安全级别取决于恶意攻击者可能进行的攻击。
- 我有一个启用 xAuth 的密钥和秘密。两者都需要由 iPhone 应用程序使用。
攻击的后果
- 恶意用户可能会伪装成来自我的应用程序发布 Twitter 状态更新。没有 Twitter 帐户可以劫持并开始发布状态更新。
bit.ly
- 我有用户名、密码和 API 密钥。
- 要登录网站并访问分析，需要用户名和密码。
- 要通过 API 创建链接，我的 iPhone 应用程序只需要用户名和 API 密钥。密码不会以任何形式存在于应用程序中。
攻击的后果
- 恶意用户可能会在我的 bit.ly 帐户上创建链接。他们需要进行单独的暴力攻击或以其他方式获取登录帐户的密码。
对于这两种服务来说，潜在的危害似乎并不太大。但对于其他服务来说，情况可能会更糟。
我可以将 API 凭据定义为标头中的字符串或代码中的内嵌字符串，但这样一来，有人在应用程序上使用字符串来查看其中的内容时，就很容易受到攻击。
然后，我可以开始在代码中进行愚蠢的串联/异或操作，以在内存中重新创建 API 密钥，而攻击者将不得不做更多的工作来恢复二进制文件中的任何密钥。我对此的担忧是，我不是密码学家，并且会在那里创建一种令人尴尬的弱混淆形式。
人们还有什么更好的建议？
The apps that I build frequently have 'social media service' requirements; e.g.
- bit.ly
For most of these services, I need to have an API key of some sort. I'm trying to work out the best way of including these API keys in the application binary. The desired level of security depends on the possible attacks that can be conducted by malicious attackers.
- I have an xAuth-enabled key and secret. Both need to be used by the iPhone app.
Fallout from attack
- Malicious users could post twitter status updates masquerading as coming from my app. There is no twitter account to hijack and start posting status updates on.
bit.ly
- I have a username, password and API key.
- To login to the website and access analytics, the username and password are required.
- To create links via the API, only the username and API key are required by my iPhone apps. The password will not be in the app in any form.
Fallout from attack
- Malicious users could create links on my bit.ly account. They would need to do a separate attack to brute-force or otherwise gain the password to login to the account.
For both of those services, the potential for harm doesn't seem too great. But for other services, it could be much worse.
I can just define the API credentials as strings in the header or in-line in the code, but then it's vulnerable to someone using strings on the application to see what's in it.
I could then start doing silly concatenation / xor-ing in the code to recreate the API key in memory, and the attacker would have to do a bit more work to recover any keys in the binary. My concern with that is that I'm not a cryptographer and would create an embarrassingly weak form of obfuscation there.
What better suggestions do people have?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
攻击者可以嗅探您的流量并从中提取秘密。因此任何混淆都很容易被规避。
即使 SSL 也没有多大帮助，因为您可以拦截接收未加密数据的网络 API。
解决此问题的安全方法是创建您自己的服务器，在服务器端保留秘密内容，并从您的应用程序使用您自己的服务器，然后服务器中继到其他 Web 服务。这样攻击者就永远无法访问秘密。
The attacker can just sniff your traffic and extract the secret from there. So any obfuscation is easily circumvented.
Even SSL won't help much, since you can intercept the networking API which receives the unencrypted data.
The secure way to solve this is create your own server, keep the secret stuff server side, and use your own server from your app, and the server then relays to the other webservice. This way the attacker never has access to the secret.
一个好的建议是不要担心。有很多应用程序以纯文本形式存储 API 密钥。关键是您需要大量不同的信息来构建访问令牌。
只要您不以纯文本形式将用户名+密码组合存储在文件系统上，或者不通过不使用 SSL/HTTPS 等的网络传输它们，就可以了。
A good suggestion is not to worry about it. There are plenty of apps that store their API keys in plain text. The point is you need a lot of different bits of information to construct an access token.
As long as you're not storing username+password combos in plain text on the file system or transmitting them over the network without SSL/HTTPS etc then you're fine.