用户表几百万行，密码从 MD5 加盐换成 bcrypt，老用户会被要求重新改密码吗？

2026年10月4日阅读：101

密码哈希的风险常出在算法速度，而不在有没有加盐

把用户密码用 MD5 或 SHA1 加盐后存进库，风险点通常不在盐，而在算法算得太快：普通显卡每秒能试上亿次候选口令，盐只挡得住彩虹表和批量比对。按 2026 年常见交付经验，更稳妥的做法是换成 bcrypt、scrypt、argon2 这类工作因子可调的慢哈希；老账号不必强制全员重置，用登录时静默升级，活跃账号常见在几周到几个月内覆盖，剩下长期不登录的账号再走兜底。

先纠一个叫法：密码存储不是加密。加密可逆，密码该是单向哈希加盐，并把校验过程做慢。团队张口就说“密码解密”，后面的方向基本就跑偏了。

加盐能解决：同一密码不产生相同存储值，彩虹表和批量比对失效。
加盐解决不了：单条哈希被拿到之后的离线爆破速度。
真正该看的指标：从拿到哈希到试出弱口令要花多少算力，而不是有没有盐。

先看库里那一列长什么样，再决定动不动手

判断不看代码写得好不好看，直接把生产库脱敏后的一条记录拿出来核对四项：有没有算法前缀、有没有独立盐字段、工作因子或迭代次数是否可见、同一个密码注册两次是否得到不同存储值。

明显要换：值是 32 位十六进制（常见 MD5 特征）或 40 位十六进制（常见 SHA1 特征），且没有算法标识。
可以缓一步：已经在用 bcrypt 或 argon2，只是工作因子偏低，调参数即可，不必改存储结构。
顺手要查：日志、异常上报、埋点里有没有把明文密码或完整请求体打进去，这类问题比换算法更急。

如果库里同时存在多种格式，别一次全改。先按格式分组统计数量，看清各占多少、哪些是活跃账号，再排迁移顺序。

迁移只能在用户下次输密码那一刻发生

密码不能反推原文，所以任何迁移都要等用户自己送上门。下面三步里，第一步和第三步容易被跳过，也容易出问题。

识别存量格式，顺带核对列长度

把库里可能的格式列全，再用小批样本验证解析逻辑。要特别留意字段长度：新算法输出常见在 60 个字符上下，如果原列是 char(32)，写进去会被截断，而部分数据库在非严格模式下并不报错，表现出来就是部分用户始终登录不上。

双读兼容，只写新格式

登录校验时按存储值前缀或长度路由到对应逻辑，新老算法并存。原则是能读旧格式、只写新格式，不要在同一列里混写两种格式再靠长度猜，后期维护成本会明显上升。

校验通过后静默升级

用户输对密码后，用新算法重算一份写回，本人无感。升级动作放在校验成功之后、响应返回之前，并且写库失败不能影响本次登录成功，避免存储抖动把正常用户挡在门外。

静默升级还是强制重置，差在打扰面和残留风险

这两条路不是对错之分，而是取舍。关键先看这批哈希是否可能已经外泄——如果发生过拖库，静默升级留下的窗口本身就是风险敞口。

强制重置：下次登录必须改密码。打扰面大，客服工单常见会上升一档；适合已确认泄露或有明确整改期限的场景，落地周期常见按天到两周计。
静默升级：用户无感，活跃账号几周内大多覆盖，但沉睡账号可能长期停在旧算法上；整体收口经验区间通常按 6~12 个月规划。
混合做法：活跃账号静默升级，长期不活跃账号缩短会话有效期或加二次校验，多数项目最后落在这一档。

交付现场与适用边界

说一个常遇到的约束：老系统仍在读同一张用户表，发版窗口只有一个晚上，联调时间也紧。按 2026 年交付经验，稳妥做法是先加一列专门存新哈希，老列不动，代码层做双读单写，第二天再跑脚本统计升级比例。代价是过渡期被拉长，经验区间是一到两成沉睡账号始终不会升级，最后还要靠强制重置或清理长期不活跃账号收尾；换来的是发版当晚几乎没有回滚风险。

适合动手的情况：系统对外提供账号体系、库里存有真实手机号或身份信息、需要应对安全评估或行业检查、多个业务共用同一张用户表。这类场景下密码哈希属于底层设施，越早改动面越小。

不必大动的情况：纯内网工具、账号由管理员统一发放并定期更换、数据不含真实个人信息的演示系统。但有一条底线——库里不存明文密码，哪怕是内部系统，因为运维账号常被复用。

一条可以单独摘出来的边界：密码哈希不是越慢越好，而是慢到让离线爆破不划算、又不拖垮登录接口的并发，工作因子要结合自身硬件压测后再定。

自检三条：脱敏后的库里看不到可识别的常见哈希长度特征；同一密码两次注册得到不同存储值；登录接口在目标并发下 P95 延迟仍在可接受范围。三条都满足，这次迁移基本站得住。