用户密码不能明文保存，也不应该用可逆加密保存。更常见的做法是保存密码哈希。bcrypt 就是专门为密码存储设计的哈希方案之一。

你可以用 bcrypt 哈希生成 / 校验工具 本地测试密码和哈希是否匹配。

bcrypt 不是加密#

加密通常可以解密回原文；bcrypt 哈希不能还原密码。登录时的流程是：

  1. 用户输入密码。
  2. 系统用同样算法计算哈希。
  3. 和数据库里的哈希比较。
  4. 匹配则登录成功。

数据库不需要知道明文密码。

salt 是什么#

bcrypt 哈希里会包含 salt。即使两个用户密码相同，生成的哈希也通常不同。

这能减少彩虹表攻击风险。你不需要单独保存 salt，因为 bcrypt 哈希字符串里已经包含相关信息。

cost 成本因子#

cost 决定计算有多慢。越高越难暴力破解，但登录计算也越慢。

选择 cost 时要结合服务器性能和登录量。不要盲目设特别高，导致正常用户登录变慢。

校验而不是解密#

如果有人问“bcrypt 怎么解密”，答案是不能解密。你只能拿候选密码去校验。

这正是它适合存密码的原因。

迁移旧密码时怎么办#

如果旧系统还在用 MD5、SHA1 或明文密码，不建议一次性要求所有用户重置。常见做法是在用户下次登录成功时，把旧密码校验通过后重新写入 bcrypt 哈希。

迁移期间要标记哈希版本，避免系统不知道某条记录应该用旧算法还是新算法校验。最终再逐步淘汰旧算法。

常见误区#

  • 把 bcrypt 哈希再 Base64 一次当作更安全。
  • 把 cost 调得过高导致登录很慢。
  • 在前端计算密码哈希后再传给后端。
  • 忘记给重置密码流程重新生成哈希。

总结#

bcrypt 适合密码存储，因为它不可逆、有 salt、可调成本。不要用 Base64、MD5 或普通 AES 来保存登录密码。

需要测试哈希和密码是否匹配时，可以用 bcrypt 哈希生成 / 校验工具，但生产系统仍应在后端安全实现。