如何使用bcrypt验证长密码？

Question

所以我遇到了这个问题，但无法弄清楚是什么原因造成的。我已经使用带有访问令牌和刷新令牌的 JWT 实现了身份验证流程。我让刷新令牌在很长一段时间后过期，并且可以强制重置它们以防止被盗的刷新令牌再次被使用。

为此，我使用 bcrypt 对 jwt 刷新令牌进行哈希处理并将其存储在我的数据库中。然而，在将原始 jwt 与哈希进行比较时，我总是得到真实的结果，但我不确定为什么。

我搜索了一些内容，我认为发生这种情况是因为 bcrypt 不喜欢 191 个字符标记，并将它们修剪到最大长度，并且由于 jwt 的第一部分是相似的，因此在比较时我得到了有效的结果哈希。这是真的？如果是这样，我如何扩展最大长度以适合我的令牌，或者我应该在将令牌传递给原始哈希函数之前对令牌进行预哈希吗？

await bcrypt.compare('loooooooooooooooooooooooooooooooooooooooooooooooooooooooong', hash);
// true

await bcrypt.compare('loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooong', hash);
// also true

任何帮助表示赞赏:)

编辑：

好吧，我已经考虑了一会儿这个问题，并认为我已经想出了一个不错的解决方案。

在签署刷新令牌时，我还生成一个随机密码并将其存储在有效负载中。我没有存储 jwt 本身的哈希值，而是将该密码的哈希值存储在数据库中。因此，每当我想验证刷新令牌没有被阻止时，我首先验证令牌本身，然后验证有效负载中的密码到我存储的哈希值。如果刷新令牌已更新，则有效负载中的密码将不再与新签名的刷新令牌中的哈希匹配，从而使其无效。

未来读者的意见？

Answer 1

并将它们修剪到最大长度，并且由于 jwt 的第一部分是相似的，因此在比较哈希时我得到了有效的结果。这是真的吗？

是的，确实如此。

无法“扩展算法的最大长度”。 bcrypt 有最大密码长度。根据算法的实现，实际限制可能会略有不同。如果您确实想使用超过该限制的密码来散列密码，则必须寻找不同的加密算法，即使字符限制更高，该算法也可能比 bcrypt 更好，也可能不更好。

Answer 2

我在 JWT 令牌长度方面遇到了同样的问题，最终使用

argon2

而不是

bcrypt

来解决最大长度问题。