我正在构建一个客户端/服务器 iPhone 游戏，我想阻止第三方客户端访问服务器。这有两个原因：第一，我的收入模式是出售客户并赠送服务，第二，我想避免助长作弊的客户激增。
我正在用 rails 编写服务器的第一个版本，但我正在考虑在某个时候转移到 erlang。
我正在考虑两种方法：
生成一个“用户名”（例如，一个 GUID）并使用应用程序附带的秘密对其进行哈希处理（SHA256 或 MD5），并将结果用作“密码”。当客户端与服务器连接时，两者都是通过 HTTP Basic Auth over https 发送的。服务器使用相同的秘密对用户名进行哈希处理，并确保它们匹配。
使用 iPhone 应用程序发送客户端证书。服务器配置为要求存在客户端证书。
第一种方法的优点是简单，开销低，并且可能更容易混淆应用程序中的秘密。
第二种方法经过了很好的测试和验证，但可能会产生更高的开销。但是，我对客户证书的了解处于“在 Delta Airlines 机上杂志中阅读”级别。这会产生多少带宽和处理开销？每个请求传输的实际数据大约为千字节。
没有办法是完美的——但挑战/回应比钥匙更好。
证书应该使用质询/响应。您发送一个随机字符串，它使用证书的私钥对其进行加密，然后您将其取回并使用公钥对其进行解密。
根据 iPhone 上这些东西的支持程度，实现这些东西将是微不足道和具有挑战性的。
我使用的一个不错的中间道路是 xor。它比密码更安全，实施起来很简单，至少需要一两个小时的时间来破解。
这只是轻微的黑客抵抗，但您可以使用其他技术使其更好，例如每次更新软件时更改密钥，用其他随机数隐藏随机数等。隐藏它有很多技巧，但最终黑客会找到它。更改每次更新的方法可能会有所帮助。
无论如何，xor 是一种黑客攻击，但它适用于发送密码有点难以破解的情况。
异或和公钥之间的区别在于，异或仅通过监控成功的对话就很容易逆转，公钥（理论上）在没有大量资源和时间的情况下是不可逆的。
你的对手是谁？这两种方法都无法防止应用程序的破解副本连接到服务器。我认为这是 iPhone 游戏（或一般）付费应用程序开发中最常见的问题。
但是，这可以保护服务器免受其他非 iPhone 客户端的影响，因为它阻止了程序员对 iPhone 和服务器之间的网络数据包接口进行逆向工程。
让您的游戏用户通过OAuth对其帐户进行身份验证，以授权他们在您的服务器上进行游戏状态更改。
如果您无法对用户进行身份验证，则需要以某种方式对您的游戏应用程序实例进行身份验证。将身份验证凭据嵌入到二进制文件中将是一个坏主意，因为应用程序盗版很普遍，并且会使您的方法高度不安全。我关于如何限制 Apple iPhone 应用程序盗版的 SO 问题可能在其他方面对您有用。