我不太介意盗版等，但我想确保后端（基于 Rails）不对可以 DOS 等的自动化服务开放。因此我想简单地确保对后端的所有访问（这将是对 GET 和 PUT 数据的一些 REST 查询）将通过有效的 iPhone 应用程序，而不是在机器上运行的某些脚本。
我想避免使用帐户，以便用户体验无缝。
我的第一个意图是将 UDID 和一个秘密散列在一起，并通过与服务器的 HTTPS 连接提供它（和 UDID）。这将允许创建经过身份验证的会话或返回错误。
如果被窃听，则攻击者可以获取哈希并重放它，从而使该方案对重放攻击开放。但是，HTTPS 连接不应该保护我免受窃听吗？
谢谢！
就像 bpapa 说的那样，它可以被欺骗，但是，就像你说的那样，你并不担心任何人来，只是连续向你的服务器发送一千个请求，而你的服务器必须处理每个请求.
您对哈希的想法是一个好的开始。从那里，您还可以将当前时间戳附加到预散列值，并将其发送。如果给定的时间戳与服务器的当前时间相差超过 1 天，则禁止访问。无论如何，这会阻止重播攻击超过一天。
另一种选择是使用随机数。任何人都可以从您的服务器请求一个随机数，但是设备必须在将哈希发送到服务器之前将其附加到预哈希数据中。必须存储生成的随机数，或者，可能只是服务器的当前时间戳。然后，设备必须将服务器的时间戳而不是其自己的时间戳附加到预先散列的数据中，从而允许发生重放攻击的时间比一整天短得多。
将 SSL 与客户端证书一起使用。在您的客户端中有一个私钥并为其颁发证书，您的 Web 服务器可以要求此客户端证书存在，以便会话继续进行。
我无法提供 Rails 的代码细节，但从架构角度来看，这是最安全的做法，尽管可能有点矫枉过正。带有证书的 SSL 是一种标准的行业解决方案，并且 iPhone/客户端和服务器端都存在库，因此您不必发明任何东西或实施太多，只需让它们很好地协同工作。
您还可以考虑 HMAC，例如 HMAC-SHA1，它基本上是这里其他人谈论的哈希值的标准化。如果您向其中添加随机数，您也可以安全地抵御重放攻击。有关如何使用 nonce 实现 HMAC-SHA1 的想法，您可以查看 OAuth 协议（不是整个流程，而是它们如何将 nonce 和其他参数绑定到经过身份验证的请求中）。
没有办法确保它，因为它可以被欺骗。
如果你真的想走这条路（老实说，除非你在这里做一些真正超级关键的任务，否则你可能会浪费你的时间），你可以传递 iPhone 设备令牌。或者也许散列它然后传递它。当然，你没有办法在服务器端或任何东西上验证它，但如果一个坏人真的想要让你失望，这里是他必须首先处理的第一个障碍。