是的，正是出于您提到的原因，您应该对密码重置令牌进行哈希处理。

但是不，它不像未散列的密码那么糟糕，因为

1. 重置令牌过期，并不是每个用户都有一个活跃的
2. 用户在更改密码时会注意到，但在密码被破解时不会注意到，因此可以采取措施限制损坏（更改密码和其他敏感数据等）。

此外，由于用户重复使用密码，攻击者可以尝试破解其他帐户的密码，例如用户的电子邮件，从而增加损失。

不，没有必要对密码重置令牌进行哈希处理，只要它们是有时间限制和一次性使用的。散列重置令牌有一些好处，但好处比密码少，所以我不会认为绝对有必要对重置令牌进行散列。

通常，密码重置令牌是有时间限制的。例如，它们可能只能使用一小时，然后就过期了。此外，通常密码重置令牌是有限的，因此它们只能使用一次，并且在使用后将被撤销。这是一个很好的做法，你绝对应该这样做。

如果您这样做，那么当密码重置令牌存储在您的数据库中时，绝对不需要对密码重置令牌进行哈希处理。让我们记住哈希旨在防御的威胁模型：它旨在缓解一次性数据库泄露。换句话说，我们假设对手发现了一个漏洞，可以让他在一个时间点转储数据库。（可能是 SQL 注入漏洞，或类似的东西。）如果发生这种情况，我们希望尽可能地限制损害。

对于密码，对它们进行哈希处理很重要。如果你不这样做，就会发生两件坏事：（i）单个数据库泄露会危及每个用户的密码，从而允许攻击者访问您网站上的每个用户的帐户；(ii) 由于用户经常在其他网站上重复使用他们的密码，这可能允许攻击者访问您在其他网站上的用户帐户。如果你做哈希，数据库泄露仍然很糟糕，但它没有那么糟糕。

对于密码重置令牌，这些都不是真的。假设您不散列密码重置令牌。然后，单个数据库违规将仅显示在违规时处于活动状态的一组重置令牌。您的网站上可能有数百万用户，但当时只有几个重置令牌处于活动状态，因此只有少数用户的帐户被暴露。这要严重得多。

此外，密码重置令牌是随机选择的，而不是由用户选择的。因此，它们不会在其他站点上重复使用，并且站点重置令牌的泄露x.com不会对其他站点上的用户帐户造成任何风险（例如，y.com）。因此，我们散列用户密码的第二个原因也不适用于重置令牌。

值得一提的是，有一种情况可以利用未散列的密码重置令牌：如果攻击者设法获得对数据库的读取访问权限，则攻击者可以为某些用户请求重置密码（alice），读取数据库以观察alice密码重置令牌，然后用它来更改alice密码并访问她的帐户。但是，这里有一些缓解因素。攻击者必须实时执行此操作，因此攻击者的时间窗口是有限的。由于电子邮件被发送到alice. 如果攻击者试图以这种方式控制许多帐户，则可能会很快发现违规行为（用户会联系网站的管理员，希望他们会进行调查）。这对试图对许多用户发起此类攻击的攻击者起到了威慑作用。它不会阻止攻击者只想影响少数用户的有针对性的攻击，但它确实降低了攻击者能够访问每个人的帐户的可能性（就像使用未散列的密码一样）。因此，未散列的重置令牌比未散列的密码更令人担忧。

不要误会我的意思。散列密码重置令牌有一些好处。但是，编写代码以散列重置令牌也需要一些努力。由于安全收益是有限的，从风险管理的角度来看，决定存储未散列的重置代币并不是荒谬的。

我不是说“不要散列重置令牌”。如果您有机会对它们进行哈希处理，请继续：您将获得一些安全优势。同时，从这个角度来看，这可能不是要实现的最重要的安全功能。您可能可以找到许多其他方法来加强站点的安全性，从而带来更大的好处。

底线：散列密码重置令牌有一些好处，但它是有限的。我不认为它是必备的安全功能。

仅对过期令牌进行哈希处理需要时间和精力。在移动应用程序中，假设 User1 请求重置密码，系统将生成一个临时 6 位令牌 + 15 分钟到期：

• 案例 1：系统将令牌直接保存到数据库中，使用令牌发送指向 User1 电子邮件的链接。User1 将在重置密码屏幕中输入令牌。工作流程还在继续……
• 案例2：系统对令牌进行哈希处理并将哈希值保存到数据库中，并使用哈希字符串发送指向User1电子邮件的链接（系统没有保存令牌而是哈希值，它只是可以发送哈希值）。在这种情况下，User1 如何获取令牌以进入重置密码屏幕？

当然，您可以为 User1 设计输入哈希，而不是令牌，但哈希不是用户友好的，不是 6 位数字。在移动应用程序中输入哈希对用户不友好，是吗？

如今，大多数移动应用程序通过发送短数字令牌/验证码来重置密码，允许用户登录系统重置密码。