如何使用 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 has a maximum password length。取决于算法的实现，实际限制可能会有所不同。如果你真的想使用超过这个限制来散列密码，你将不得不寻找一种不同的加密算法，即使有更高的字符限制，它也可能比 bcrypt 更好，也可能不更好。