密码邮件证明的是可逆性，而不是存储方案

把用户当前密码用邮件发出的服务证明了一件事：它能以可发送的形式取得该秘密。但它没有证明是哪一列、哪种算法或哪个库生成了它。这一区分很重要，因为发现是真实的，而人们由此得出的结论通常过于具体。路径中某处的可逆性才是机制；被猜测的存储格式不是。

把证据保持在这一层，评审的其余部分就仍然准确。

把旧秘密回寄出去证明了什么

单向校验器无法生成原始密码，因为它被设计成不可逆。如果服务能把密码用邮件发出，那么此刻它持有可从中恢复密码的材料，或者在哈希之前截获并保存了明文。无论哪种，恢复路径都是可逆的，这是真正的安全发现。它并没有说明同一个数据库对其它列是否使用了高成本哈希。

也要注意中间情形：保存的密文块若密钥由应用持有，实践中就是可逆的，尽管加密一词在报告里听上去令人安心。

为什么这是设计发现，而不是存储地图

邮件证明的是可恢复性，并不指向确切的方案。它可能是明文、确定性加密、厂商的混淆例程，或仅用于恢复的独立凭据存储。产品的不同部分常常使用不同的存储。仅凭一封邮件就指定算法，是那种在后续会议上站不住脚的说法。

你能说的更窄也更有用：这条路径可以恢复秘密，因此产品不能声称不存在可恢复的凭据。除此之外的一切都需要运营方提供证据。

围绕授权来构建重置

重置解决的是另一个问题：证明请求者有权选择新密码。OWASP 的相关指南描述了安全生成、带适当有效期的单次令牌或验证码，并把请求阶段视为需要防范枚举与洪泛的环节。未经认证的请求不得自行更改账户。在接受替换之前先校验授权，并让令牌在一次成功使用后失效。

邮件通道是安全模型的一部分。拥有一个账号名并不能证明什么，而暴露账号是否存在的重置流程反而给了攻击者一份可用的名录。

让密码曾保护的一切失效

更改密码不会自动终止它曾授予的访问。活跃的 VPN 会话、被记住的设备和服务器签发的令牌，可能各有各的失效行为。要有意识地决定哪些必须结束，并验证实现确实做到了，因为以为重置已在所有地方退出登录的用户往往是错的。把这一决定与流程一起记录下来。

对运营方：记录哪个组件校验请求、哪个组件更改凭据，以及相关会话如何处理。对用户：保护好合法的恢复通道，并把任何回寄密码的消息都视为可疑。

准确的评估很短：这条消息证明了什么，还有什么仍然未知，以及恢复是否通过受控流程取代了访问。