在 cookie 中使用 bcrypt 生成的盐作为令牌代替密码是否安全?

信息安全 密码 饼干 bcrypt
2021-08-30 19:03:45

我有一个仅在 SSL 上运行的(爱好)网站。该网站不涉及财务、社会安全号码或任何具有同等重要性的内容。但是,我想尽可能合理地保护它。Cookie 被标记为安全和 httponly。密码使用 bcrypt 存储在服务器端。

我正在尝试为那些想要使用它的用户实现“记住我”。仔细阅读这个网站,我知道您不想在 cookie 中存储密码;相反,您希望存储一个允许非关键使用的“令牌”,但随后提示输入关键操作的实际密码(例如,更改密码)。

而不是随机生成一个令牌,然后创建一些匹配的数据库(或其他方法),使用从 bcrypt 随机生成的盐作为 cookie 中的令牌是否太不安全?

优点是:

  1. 在对密码进行哈希处理时生成,因此无需额外费用或代码
  2. 与密码一起存储,因此可以根据需要查找和匹配
  3. 独特的

缺点可能是:

  1. 令牌不会从会话更改为会话

如果 cookie 以某种方式被盗,它只允许对站点进行非关键访问。也就是说,它不会显示实际密码,密码不能更改,与帐户关联的电子邮件也不能更改。

我是否忽略了上述方案中的任何严重问题?

3个回答

我的两分钱,你没有忽略任何东西。你的方案是正确的。但请注意,您所做的事情并不安全。每个会话的会话 ID 应该是唯一的。为什么你可能会问?

那么建议攻击者能够窃取cookie。然后他可以以该用户身份登录。直到用户注销,因为那时会话 id 过期。但是,如果您的会话 ID 在所有会话中保持不变,则攻击者将能够继续以用户身份登录,而不管用户是否注销。

简而言之,这意味着,一旦攻击者窃取了 cookie,他将拥有该用户会话的永久密钥(除非用户更改密码)。请意识到这被认为是高风险的。这种攻击的影响可能相当大。

不要这样做。

如果攻击者通过网络嗅探会话 ID,则攻击者现在可以有效地永久访问用户帐户。同样糟糕的是,如果您知道这已经发生,您将无法使会话过期,因为您无法在没有用户密码的情况下重新生成 bcrypt 摘要。

不要试图有创意。在每次新访问时生成一个随机令牌,并在登录时重新生成它以避免会话固定攻击(攻击者将用户的会话 ID 设置为他知道的值,然后等待用户登录,然后再使用该 ID 访问站点) .

除了上面的答案,处理会话令牌对于每个会话是随机的和不同的需求,公开暴露密码哈希的盐还有另一个风险。

虽然盐并不意味着保密,但同时公开它们也不是一个好主意。这是因为知道盐的攻击者可以在获得散列密码的副本之前为这个特定的盐构建彩虹表。

当他确实获得了散列密码的副本(例如通过 SQL 注入攻击)时,他现在可以立即尝试查找他已经为其构建彩虹表的散列值。从而最大限度地减少攻击和被盗数据的实际恶意使用之间的时间。

多项式比我能更好地回答这个问题