我有一个跟踪点击的 URL,我想阻止用户共享该 URL。
因此,我的想法是创建一个唯一的 URL,该 URL 具有一个字符串,该字符串是某种加密时间戳(带有盐),如果在该加密时间戳的 5 分钟内单击该链接,那么它将是有效的。
有一个更好的方法吗?如果不是,我将如何解密它,因为生成它的时间戳与单击它的时间戳在大多数情况下会有所不同?
我有一个跟踪点击的 URL,我想阻止用户共享该 URL。
因此,我的想法是创建一个唯一的 URL,该 URL 具有一个字符串,该字符串是某种加密时间戳(带有盐),如果在该加密时间戳的 5 分钟内单击该链接,那么它将是有效的。
有一个更好的方法吗?如果不是,我将如何解密它,因为生成它的时间戳与单击它的时间戳在大多数情况下会有所不同?
我认为已经给出的评论和答案过于复杂。这个问题似乎类似于密码重置链接。你可以:
生成一个随机令牌并将其加盐哈希(或PBKDF2(token, salt)以增加安全性)连同到期时间一起存储在数据库中。
每当有人使用该 URL 时,对其进行哈希处理并根据您存储的副本对其进行验证,并确保时间没有过期。
任何“加密时间戳”方案仍然存在如何安全处理该 AES 密钥的问题。要么你有一个需要存储的随机密钥,要么它是可派生的,在这种情况下它是不安全的。
您的威胁模型可能应该假设应用程序或数据库的妥协将导致另一个妥协。在这种情况下,只需存储令牌而不增加复杂性。
如果您仍想在 URL 中嵌入时间戳,您可以查看Azure 共享访问签名的工作方式,其中包括 URL 中的 SHA256-HMAC。
提供页面时,生成转换为时区 UTC 的时间戳。对称加密(例如使用 AES-256)并将其放在 URL 中。
当用户要求访问具有此类加密时间戳的 URL 时,请使用相同的密钥对其进行解密(编辑:使密钥成为相关内容的加盐哈希,以便每个不同的内容都有不同但始终相同,钥匙)。如果时间戳与转换为时区 UTC 的服务器时间戳相比不到 5 分钟,则拒绝它,否则接受它。
用户无法通过输入不同的加密时间戳来欺骗您,因为他们不知道也无法找到您的密钥(即使知道它会是什么时间戳并且加密算法也没有提供足够的信息来找出您的密钥) key) 并且所有的时间戳选择和比较都是在服务器端完成的。
编辑:通过编辑,他们也不能获取对一个内容有效的时间戳并将其附加到对另一个内容有效的时间戳。