跳至主要內容

为什么忘记密码时只能重置，不能告诉你原密码？

Guide系统设计数据安全密码安全哈希算法面试题约 3048 字大约 10 分钟

这是一个挺有意思的问题，很多公司也在面试中问过。挺简单的，不知道大家平时在重置密码的时候有没有想过这个问题。

重置帐号密码

回答这个问题其实就一句话：因为服务端也不知道你的原密码是什么。存原密码的程序员已经被开了 🤣。

如果服务端知道你的原密码，那就是严重的安全风险问题了。

我们这里来简单分析一下。

这篇文章不会谈论太多加密算法相关的内容，感兴趣的朋友可以看这篇文章：常见加密算法总结。

为什么服务端不知道你的原密码？

做过开发的应该都知道，服务端在保存密码到数据库的时候，绝对不能直接明文存储。

如果明文存储的话，风险太大：

  1. 数据库数据有被盗的风险
  2. 有数据库权限的内部人员可能恶意利用
  3. 黑客入侵后可以直接获取所有用户密码

因此，密码必须经过处理后才能存储。这个处理方式就是使用哈希算法。

哈希算法简介

哈希算法也叫散列函数或摘要算法，它的作用是对任意长度的数据生成一个固定长度的唯一标识，也叫哈希值、散列值或消息摘要（后文统称为哈希值）。

哈希算法效果演示

哈希算法有两个关键特点：

  1. 不可逆性：你无法通过哈希之后的值再得到原值。这是核心！
  2. 确定性：相同的输入永远产生相同的输出。

有个很形象的比喻：你存的密码就像切过的土豆丝，不能被复原成土豆。但网站判断密码是否正确的方式，就是把你输入的新密码当成土豆再切一次，看看这两盘土豆丝是不是一样的。

这两个特点决定了哈希算法非常适合用于密码存储：服务端只存储密码的哈希值，验证时只需比较哈希值是否一致。

哈希算法的分类

哈希算法可以简单分为两类：

  1. 加密哈希算法：安全性较高的哈希算法，它可以提供一定的数据完整性保护和数据防篡改能力，能够抵御一定的攻击手段，安全性相对较高，但性能较差，适用于对安全性要求较高的场景。例如 SHA2、SHA3、SM3、RIPEMD-160、BLAKE2等等。
  2. 非加密哈希算法：安全性相对较低的哈希算法，易受到暴力破解、冲突攻击等攻击手段的影响，但性能较高，适用于对安全性没有要求的业务场景。例如 CRC32、MurMurHash3等等。

除了这两种之外，还有一些特殊的哈希算法，例如安全性更高的慢哈希算法。

为什么不推荐 MD5？

早期常用 MD5 来加密密码，但现在已经不被推荐，原因如下：

  1. 抗碰撞性差：存在弱碰撞问题，即多个不同的输入可能产生相同的 MD5 值。
  2. 哈希值较短：128 位的哈希值容易被彩虹表攻击。
  3. 计算速度太快：反而容易被暴力破解。

详细介绍可以阅读这篇文章：简历别再写 MD5 加密密码了！

为什么需要加盐？

单纯使用哈希算法存储密码，仍然存在被彩虹表攻击的风险。彩虹表是一种预先计算好的哈希值对照表，攻击者可以通过查表的方式快速破解密码。

盐（Salt）是为每个密码独立生成的随机值，密码哈希算法会把盐和密码一起参与计算。盐不需要保密，但必须随机且不能在所有用户之间复用。

加盐的作用：

  1. 增加密码的复杂度和唯一性。
  2. 使得彩虹表攻击失效（每个用户的盐都不同）。
  3. 即使两个用户使用相同密码，哈希值也不同。

密码存储方案推荐

密码应使用专门为密码存储设计、可调节计算成本的算法，而不是直接使用 MD5、SHA-256、SHA-3 这类高速哈希算法。即使给高速哈希加盐，攻击者拿到数据库后仍然可以高速尝试大量候选密码。

新系统优先考虑 Argon2id。如果不可用，可以根据运行环境选择 scrypt；兼容遗留系统时可以使用合理配置的 Bcrypt；有 FIPS 合规要求时可以使用 PBKDF2。具体参数需要结合服务器性能定期评估和升级。

Bcrypt 示例

Bcrypt 是专门为密码存储设计的哈希算法，属于慢哈希算法。它内置了 salt 机制和 cost（成本）参数：

  • salt：随机生成的字符串，用于和密码混合，增加密码的唯一性
  • cost：控制迭代次数，增加计算时间和资源消耗

Bcrypt 的随机盐可以防止预计算和彩虹表攻击，cost 参数可以提高离线猜测成本，但无法让弱密码变得不可破解。还要注意，多数 Bcrypt 实现只处理密码的前 72 个字节，系统不能在没有提示的情况下静默截断密码。

Spring Security 提供了 BCryptPasswordEncoder。下面以它演示如何显式设置 cost；新系统选型仍应优先评估 Argon2id：

@Bean
public PasswordEncoder passwordEncoder(){
    // cost 应通过性能测试确定，并随着硬件能力提升定期调整。
    return new BCryptPasswordEncoder(12);
}

登录验证流程

当你输入密码登录时，验证流程如下：

  1. 服务端根据用户名从数据库取出该用户保存的密码哈希编码。这个编码通常已经包含算法标识、参数和随机盐。
  2. 服务端调用密码哈希库提供的验证方法，例如 Spring Security 的 PasswordEncoder#matches。不要自己拼接盐值，也不要直接比较字符串。
  3. 密码库读取编码中的盐值和参数，对用户输入进行同样的计算，并以安全方式比较结果。
  4. 如果验证通过，说明密码正确；否则密码错误。验证成功后还可以在参数过旧时重新计算并升级密码哈希。

重置密码时如何判断新密码与旧密码相同？

细心的同学可能发现，有些网站在重置密码时会提示"新密码不可与旧密码相同"。那网站是怎么知道新密码和旧密码相同的呢？

其实原理和验证密码正确性一样：

  1. 用户输入新密码。
  2. 服务端调用密码哈希库的验证方法，用新密码验证数据库中的旧密码哈希，例如 passwordEncoder.matches(newPassword, oldPasswordHash)。
  3. 如果验证通过，说明新密码和旧密码一样，拒绝修改。
  4. 如果不相同，则为新密码重新生成随机盐和密码哈希，不能复用旧哈希或自行固定盐值。

所以网站并不知道你的旧密码是什么，只是比较了两盘"土豆丝"是否一样。

密码传输安全

前面讲的都是密码在服务端的存储安全，那密码在传输过程中安全吗？

有个常见的面试问题：如果某个员工知道加密方式，那岂不是他可以在私下或者离职后拦截包然后模拟加密从而获取密码？

答案是：存储与传输本身就是分开处理的。

完整的密码安全方案需要同时保障存储安全和传输安全。

使用 HTTPS

HTTPS 协议是保障传输安全的基础。HTTP 协议运行在 TCP 之上，所有传输的内容都是明文，客户端和服务器端都无法验证对方的身份。HTTPS 则是运行在 SSL/TLS 之上的 HTTP 协议，所有传输的内容都经过加密。

关于 HTTP 和 HTTPS 的详细对比可以看这篇文章：HTTP vs HTTPS（应用层）。

对于普通 Web 应用，正确配置的 HTTPS 是密码传输安全的基础方案。服务端应默认使用 TLS 1.3，并按兼容性需要支持 TLS 1.2；全站强制 HTTPS，启用 HSTS，正确校验证书并禁用过时协议和弱密码套件。

浏览器再使用一层自定义 RSA 加密，通常不能解决恶意客户端、被攻陷的前端脚本或服务端解密点泄露密码的问题，反而会增加密钥分发、填充选择和密文重放等风险。因此，不要把“客户端 RSA + HTTPS”当作所有系统都必须采用的通用方案。

某些具有明确合规要求或特殊威胁模型的系统可能会在 TLS 之上增加应用层保护，但应使用经过评审的成熟协议，并同时包含随机挑战、时效校验和防重放机制，不能只做一次简单的公钥加密。

除了传输加密，还应限制登录尝试、避免记录密码、使用多因素认证，并防范凭据填充和撞库攻击。

忘记密码流程还要注意什么？

本文重点解释为什么服务端不能找回原密码。实际实现忘记密码功能时，还需要注意下面这些安全要求：

  • 无论账号是否存在，都返回一致的提示，并尽量保持接近的响应时间，避免用户枚举。
  • 重置令牌使用密码学安全随机数生成，具备足够熵，只能使用一次，并在较短时间后过期。
  • 对重置请求和令牌校验进行限流；重置链接只使用可信域名和 HTTPS，避免令牌通过 Referer 泄露。
  • 密码修改成功后发送安全通知，并根据风险使已有会话失效，或至少让用户能够一键注销其他会话。

总结

回到最初的问题：为什么忘记密码时只能重置，不能告诉你原密码？

因为服务端存储的是密码经过哈希算法处理后的值，哈希算法是不可逆的，无法从哈希值还原出原始密码。这是密码安全的基本原则。

如果一个网站能够直接告诉你原密码，说明服务端以明文或可逆形式保存了可恢复的密码，而不是只保存专用密码哈希。这是严重的安全隐患，建议立即修改密码，并检查其他网站是否复用了同一密码。

更重要的是：如果你在所有网站都用了相同的密码，一个不靠谱的网站泄漏了你的密码，就相当于你所有的账户都面临风险。所以，不要在所有网站使用相同密码！

参考