Ios 移动应用程序的API时间戳限制

正在研究为移动应用程序实现API安全层。使用请求时间戳并拒绝旧的请求将是许多检查中的一次。以下是一些与时间戳有关的问题：

移动设备可能会出现时间偏差

设备可能连接速度慢，导致请求延迟到达服务器

最小化的应用程序可能不会立即发送获取请求（至少在iOS上）

请求或连接可能只是在设备上超时

---

记住以上所有内容，是否会对理想的时间戳阈值有某些建议？我理解这可能需要逐案考虑，阈值应根据所需的安全级别设置。只是想知道之前是否已经做过这样的事情，还有哪些参数需要考虑呢？

为什么你认为用“旧”<代码>日期<代码>标题值拒绝消息是一种安全实现？不仅可以伪造头值（特别是当值来自系统时间时），而且我不确定带有过去日期的消息如何表示安全问题。也许您希望将重点放在使用公钥/私钥对消息体进行散列，将私钥用作salt。该摘要可用于提供签名头值，这将允许您对中间人攻击具有安全性，并消除对纯文本密码的需要。使用时间戳是我正在实现的安全算法中的几层之一。时间戳保证请求是最近的，并且在哈希中使用相同的时间戳保证时间戳不会被伪造。我的算法非常符合你上面的建议。问题在于时间戳本身，因为移动应用程序的限制在web应用程序中通常不会遇到。我仍然不确定为什么“旧”请求会引起安全问题。如果您希望在一段时间后使客户机发出请求的能力过期，为什么不发出一个与过期绑定的访问密钥呢？如果您想确保一个请求不会被多次处理，为什么不发出一个nonce令牌呢？至于时间戳，在你的哈希函数运行之前，我仍然可以在我的设备上伪造系统时间，从而将我伪造的时间戳包含到你的哈希中。很好。在这种情况下，旧请求意味着有人试图复制过去发出的请求，从而意味着某种攻击。我的方法基于Amazon在签名版本4签名过程中设置的标准。它看起来非常优雅和安全。我熟悉AWS签名4。AWS拒绝任何比当前时间早5分钟以上的消息，事实上，这些消息可以防止重播攻击。但是，请记住，在五分钟内，该请求将受到重播攻击。如果您正在对RESTful端点执行POST请求，那么在5分钟内可能会造成相当大的损害。在这种情况下，临时措施是适当的防御措施。