这个计划是为了防止iPhone应用程序客户端欺骗声音吗？
我正在设计一个通过 HTTP 与服务器通信的 iPhone 应用程序。
我只希望应用程序（而不是任意 HTTP 客户端）能够 POST 到服务器上的某些 URL。 因此，我将服务器设置为仅验证包含秘密令牌的 POST，并将应用程序设置为包含该秘密令牌。 包含此令牌的所有请求将仅通过 HTTPS 连接发送，因此无法嗅探。
你认为这个推理有什么缺陷吗？ 例如，是否可以使用“字符串”、十六进制编辑器等从编译的应用程序中读取令牌？ 当然，我不会以 .plist 或其他纯文本格式存储此令牌。
欢迎提出替代设计的建议。
I'm designing an iPhone app that communicates with a server over HTTP.
I only want the app, not arbitrary HTTP clients, to be able to POST to certain URL's on the server. So I'll set up the server to only validate POSTs that include a secret token, and set up the app to include that secret token. All requests that include this token will be sent only over an HTTPS connection, so that it cannot be sniffed.
Do you see any flaws with this reasoning? For example, would it be possible to read the token out of the compiled app using "strings", a hex editor, etc? I wouldn't be storing this token in a .plist or other plain-text format, of course.
Suggestions for an alternate design are welcome.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
一般来说，假设坚定的攻击者无法发现嵌入在其物理控制下的设备上的应用程序中的密钥（并且可能无论如何他都拥有）是没有根据的。 看看所有依赖此假设的损坏的 DRM 方案。
真正重要的是谁想得到钥匙，以及他们的动机是什么。 销售针对不急于偷窃的人群的产品。 给你的产品定价，让购买它比发现钥匙更便宜。 为您的客户提供良好的服务。 这些都是营销和法律问题，而不是技术问题。
如果您确实嵌入了密钥，请使用要求每个客户端自行发现密钥的方法，例如要求每个客户端使用不同的密钥。 您不希望出现这样一种情况：攻击者可以发现密钥并发布它，从而授予每个人访问权限。
iPhone 确实提供了“KeyChain”API，这可以帮助应用程序向设备所有者隐藏秘密，无论好坏。 但是，任何东西都是易碎的。
In general, assuming that a determined attacker can't discover a key that is embedded in application on a device under his physical control (and, probably, that he owns anyway) is unwarranted. Look at all of the broken DRM schemes that relied on this assumption.
What really matters is who's trying to get the key, and what their incentive is. Sell a product aimed at a demographic that isn't eager to steal. Price your product so that it's cheaper to buy it than it is to discover the key. Provide good service to your customers. These are all marketing and legal issues, rather than technological.
If you do embed a key, use a method that requires each client to discover the key themselves, like requiring a different key for each client. You don't want a situation where one attacker can discover the key and publish it, granting everyone access.
The iPhone does provide the "KeyChain" API, which can help the application hide secrets from the device owner, for better or worse. But, anything is breakable.
据我理解，是的，可以通过某种方式从应用程序中检索密钥。 由于 Objective-C 运行时的本质，几乎不可能隐藏某些内容。 据我所知，只有 Omni 通过序列号对其进行了管理，显然是通过将关键代码保留在 C 中 (可可不安全)。
这可能需要大量工作（我不知道实现起来有多复杂），但您可能需要考虑使用推送通知每小时向程序发送一个有效期为一小时的身份验证密钥。 这将在很大程度上将验证它是你的应用程序的问题转移给苹果。
The way I understand it, yes, the key could be retrieved from the app one way or another. It's almost impossible to hide something in the Objective-C runtime due to the very nature of it. To the best of my knowledge, only Omni have managed it with their serial numbers, apparently by keeping the critical code in C (Cocoa Insecurity).
It might be a lot of work (I've no idea how complex it is to implement), but you might want to consider using the push notifications to send an authentication key with a validity of one hour to the program every hour. This would largely offload the problem of verifying that it's your app to Apple.
我建议根据发送的数据和您的应用程序和服务器知道的密钥添加一些校验和（md5/sha1）。
I suggest to add some checksum (md5/sha1) based on the sent data and a secret key that your app and the server knows.
应用程序可以被反汇编，以便它们可以找到您的密钥。
Applications can be disassembled so that they could find your key.
需要更多信息来确定该方法是否合理。 一项受保护的资产可能是健全的，而另一项资产则不健全，这一切都基于资产的价值和资产被泄露的成本。
一些早期的海报提到了这样一个事实：设备上的任何内容都可以被坚定的攻击者泄露。 因此，您能做的最好的事情就是确定资产的价值，并为攻击者设置足够的障碍，使攻击成本超过资产的价值。
人们可以将 SSL 客户端证书添加到您的方案中。 人们可以将该证书和令牌的密钥深埋在一些混淆的代码中。 人们可能可以使用公钥/私钥加密技术来制定一种方案来进一步模糊令牌。 人们可以实现一种具有时间限制响应时间的质询/响应协议，其中服务器质询应用程序，并且应用程序在断开连接之前有 X 毫秒的时间进行响应。
障碍的数量和复杂性都取决于资产的价值。
杰克
More information is needed to determine whether the approach is sound. It may be sound for one asset being protected and unsound for another, all based on the value of the asset and the cost if the asset is revealed.
Several earlier posters have alluded to the fact that anything on the device can be revealed by a determined attacker. So, the best you can do is determine valuable the asset is and put enough hurdles in the way of the attacker that the cost of the attack exceeds the value of the asset.
One could add to your scheme client-side certificates for the SSL. One could bury that cert and the key for the token deep in some obfuscated code. One could probably craft a scheme using public/private key cryptography to further obscure the token. One could implement a challenge/response protocol that has a time boxed response time wherein the server challenges the app and the app has X milliseconds to respond before it's disconnected.
The number and complexity of the hurdles all depend on the value of the asset.
Jack
您应该研究 Entrust Technologies (www.entrust.com) 产品线，以获取与各种具体信息（例如设备、IMEI、应用程序序列号、用户 ID 等）相关的双因素身份验证。
You should look into the Entrust Technologies (www.entrust.com) product line for two-factor authentication tied to all sorts of specifics (e.g., device, IMEI, application serial number, user ID, etc.)