Ruby Devise 身份验证组件生成的remember_user_tokencookie 令牌在解码时会显示 bcrypt 加盐凭证的一部分。
例如：
remember_user_token=W1sxNF0sIiQyYSQxMSRtSHhGeWd3VkFNdzdxd3VmUE04MWdPIiwiMTUyMTA4NjEzMy4wOTU3Il0%3D--96341f2abb8e9fa777d9ad5199b2231f3d22e1d7
解码为：
[[14],"$2a$11$mHxFygwVAMw7qwufPM81gO","1521086133.0957"]
这个元组的第二部分是 bcrypt 到 salt 的凭据。
由于省略了散列密码部分，我相信恢复密码是不可行的。但是，这似乎不是一个好的做法，我不清楚为什么这个函数被设计为甚至显示用户的一部分哈希凭据。
在哪些情况下，此信息可能会帮助攻击者获得对应用程序的未经授权的访问？
源代码如下：
“可记住”的设计策略用于从具有以下格式remember_user_token的持久 cookie（您解码的）中存储的值重新验证用户：
[[<user_id>], "<user_salt>", "<cookie_generated_at_UTC_time>"]]
对 cookie 进行签名是为了防止篡改 cookie 值（签名是您可以在 cookie 中的“--”之后找到的 blob）。
您正在测试的应用程序使用“rememberable”的默认实现，它不需要有一个数据库列来存储每个用户的“remember tokens”；相反，它使用用户 id + 密码 salt 作为唯一标识用户的密钥。当应用程序接收到签名的id+saltcookie 时，它会查找匹配的用户，id如果salt匹配的 cookie 匹配，则成功验证用户并继续处理。
使用盐作为唯一标识符避免了在服务器端存储“记住令牌”；作为权衡，它揭示了盐。让攻击者在没有实际哈希密码的情况下访问 bcrypt salt 是没有用的（salt 仅用于避免预先计算的哈希攻击，迫使攻击者分别暴力破解每个哈希密码）。如果攻击者获得了用户密码的访问权，他们也将获得对 salt 的访问权，因此“rememberable”策略的安全性不会因共享 salt 而受到损害。
我个人会更关心用户 ID（cookie 中的第一个字段）的共享，例如，它可能稍后在直接对象引用攻击中重新使用。
如果您不习惯公开用户密码 salt，您可以remember_token在您的 Devise 用户类中实现您自己的方法，参见可记忆模型，例如创建随机令牌并将它们存储在用户数据库表中。