“记住我”cookie 的哈希值或令牌？答案

【问题标题】：Hashes or tokens for "remember me" cookies?“记住我”cookie 的哈希值或令牌？
【发布时间】：2012-01-06 12:43:46
【问题描述】：

说到记住我 cookie，有两种不同的方法：

哈希
记住我 cookie 存储了一个可以识别用户的字符串（即用户 ID）和一个可以证明所识别的用户是它假装的用户的字符串 - 通常是基于用户密码的哈希.

代币
remember me cookie 存储一个随机（无意义）但唯一的字符串，该字符串与 tokens 表中的记录相对应，该表存储用户 ID。

哪种方法更安全，它有什么缺点？

【问题讨论】：

直觉表明一次性随机字符串必须比算法产生的确定性字符串更安全，但我想您需要一些参考。无论如何，直觉并不总是正确的。
为什么标记为 Ruby？
对于找到此内容的任何人，请阅读：Persistent Login Cookie Best Practice。基本上，您还需要以与哈希密码相同的方式对令牌进行哈希处理。

【解决方案1】：

是的，如果每次都生成随机字符串，令牌会更安全。

另一方面，记住我的重点是用户不必再次登录，因此除非他们单击注销，否则您很少需要重新生成新令牌，除非它过期。

我想你应该坚持使用令牌而不是为了懒惰而牺牲安全性：-p

【讨论】：

【解决方案2】：

通常您会在服务器端保持令牌 -> 用户映射的安全。因此，最终您的安全性完全基于保持令牌安全并确保其生命周期受到控制（例如，它过期和/或仅在从与原始凭证提供者使用的 IP 相同的 IP 提供给您时才有效 - 再次，只是一个例子）

希望这会有所帮助。

【讨论】：

【解决方案3】：

如果可能，您应该使用随机生成的令牌。当然，缺点是您必须编写一些额外的代码来在服务器端存储和使用它们，因此这可能不适用于所有 Web 应用程序。但从安全的角度来看，这具有明显的优势：

攻击者无法从用户 ID 生成令牌，但他绝对可以生成哈希。这是一个大问题，即使您在生成哈希时使用了 salt（并且应该这样做），如果 salt 落入坏人之手，您的用户就会被搞砸。
提供这些令牌使您的用户（或您的管理员，如果需要）能够“注销”他们可能想要摆脱的某些会话。这实际上是一个很酷的功能，例如 Google 和 Facebook 使用它。

所以，如果你有时间和预算：绝对是代币。

【讨论】：