如何使用bcrypt验证长密码？

Question

我遇到了这个问题，但无法确定是什么原因。我使用JWT（JSON Web Token）实现了认证流程，并分别使用访问令牌和刷新令牌。我将刷新令牌设置为长时间后过期，并可以强制重置以防止盗用的刷新令牌再次被使用。

为此，我使用bcrypt对jwt刷新令牌进行哈希处理并将其存储在我的数据库中。然而，当比较原始jwt和哈希值时，我始终得到true的结果，不确定原因所在。

我搜索了一些信息，认为这可能是因为bcrypt不支持191个字符的令牌，并将其裁剪到最大长度，由于jwt的前半部分相似，因此比较哈希值时会得到有效结果。如果是这样，我该如何扩展最大长度以适应我的令牌？或者应该在传递给原始哈希函数之前对令牌进行预处理？

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

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

需要任何帮助 :)

编辑：

好的，我思考了一下，认为我想出了一个还不错的解决方案。

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

未来读者的意见？

- Kipnoedels

---

那需要我也存储原始的令牌，不是吗 :P - Kipnoedels

Answer 1

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

是的，这是正确的。

无法“扩展算法的最大长度”。bcrypt 有一个最大密码长度。根据算法实现的不同，实际限制可能略有不同。如果您确实想使用超过该限制的字符数来哈希密码，您将需要寻找不同的加密算法，即使具有更高的字符限制，该算法也可能比 bcrypt 更好或更差。

- Hanchen Jiang

---

好的，我觉得结果为 true 有点奇怪。如果库能检查 input > maxLength 并取消调用以防止这种情况发生会更好。 - Kipnoedels