通过邮件重置用户密码的正常流程是这样的：
但是，维护表格和过期旧字符串等似乎有点不必要的麻烦。这种替代方法是否有任何明显的缺陷？
请注意，用户的密码已经以散列和加盐形式存储，我只是再次对其进行散列以获得唯一但可重复的字符串。
是的，有一个明显的“缺陷”：在用户更改密码（单击链接）之前，由此生成的重置链接不会过期。不过，我真的不明白为什么这会是个问题——如果邮箱被盗，无论如何用户都会被搞砸。并且不存在重复使用的风险，因为一旦用户密码更改，重置链接将不再匹配。
要解决此obvious flaw问题，请将当前日期（以及更多与时间相关的信息表示一天中的当前部分，如果一天太长的话）添加到您正在散列的内容中以生成神秘字符串并检查它 - 这使得字符串“过期”（如果您想要更长的“过期时间”，您可以检查前一个和当前日期或分数）。所以在我看来，你的方案是相当可行的。
如果有人使用密码哈希访问您的数据库，他们将不知道实际密码。如果您实施此系统，那么他们可以生成重置链接并自行重置密码。使用随机字符串和泄露信息，您可以使所有随机字符串无效，并且即使不知道访问权限，也只有正在重置密码的用户才会受到威胁。不太可能出现这种情况，但考虑到随机字符串的名义开销，可能值得考虑。
实际上，在再次考虑这一点之后，您的方法可能不如“正常流程”安全。
如果您只是发回HASH(HASH(user's original password))，我可以看到这可以给攻击者利用的场景：
场景一：
Jim在您的网站上注册为jimjones@microsoft.com.Jim请求重置密码，但不使用它。重置的电子邮件永远留在他的收件箱中。Jim更改他在您网站上的电子邮件地址。jimjones@gmicrosoft.com被Bob.Bob现在通过他的分布式 GPGPU 农场进行暴力攻击并恢复Jim的密码。场景二：
Jim使用jimjonesupinthisma!他的银行帐户的密码。Jim在您的网站上注册为jimjones@microsoft.com. jimjones@microsoft.com与您的银行账户没有任何关联。Jimjimjones@gmicrosoft.com被Bob.Bob现在请求重置，他现在有HASH(HASH(jim's password))。Bob现在通过他的分布式 GPGPU 农场进行暴力攻击并恢复Jim的密码，然后他使用该密码访问Jims 银行帐户。场景 3：
（您的站点使用 TLS，用户通过 TLS 注册。）
Jim在您的网站上注册为jimjones@microsoft.com.Bob请求重置Jims 帐户的密码。Bob在641A 房间为 NSA 工作。Bob使用他的全球互联网嗅探器并HASH(HASH(jim's password))以明文形式通过电子邮件发送到jimjones@microsoft.com.Bob现在通过他的分布式 GPGPU 农场进行暴力攻击并恢复Jim的密码。场景 1 和 2 的变体一直发生（取决于哈希和密码的强度），我不太确定 3。关键是，您的方法会泄露不必要的信息，这确实可以利用攻击者攻击您的用户.
我建议您使用与用户密码无关的随机生成的令牌。
假设在一个非常罕见的情况下，您的两个用户即使在将随机盐连接到它之后也具有相同的哈希密码；会有问题吧？我想如果您将 user_id 的电子邮件或哈希值添加到重置密码链接中，这不会有什么坏处。
刚刚路过这个问题，有个想法：
1) 发布一个 JWT（Json Web 令牌），其中包含有关用户帐户的信息。令牌有一个过期时间，比如 1 小时。
2）通过电子邮件/链接将令牌发送给用户
3) 用户点击链接，令牌被发送到服务器端点，令牌被验证。如果有效，则解压缩令牌并更新用户帐户
这种方法有什么缺陷吗？未触及数据库（必要时新用户密码除外）