密码改造背景与挑战：为什么我们需要动这套老系统？
说实话，这些年我见过太多密码体系“裸奔”的系统了。有一家银行的内部管理平台，2015年上线后就没动过密码存储方式——用户密码明文存库，连MD5都没做。直到某次渗透测试，测试人员横向拖库后直接登录了所有管理员账户。嗯，那次事故之后，整个集团才开始正视密码改造。
密码改造，说白了就是把已经过时、不安全或不符合监管要求的密码技术换掉。这活儿看着简单，实际上一脚踩下去全是坑。我个人习惯在动手前先问三个问题：为什么要改？改什么？改坏了怎么办？
为什么非改不可？
你想想看，现在的攻击手段和十年前完全不是一个量级。GPU暴力破解、彩虹表、撞库脚本……老密码体系在这些面前就跟纸糊的一样。加上《数据安全法》《个人信息保护法》对密码合规的要求越来越严，不改？等着吃罚单吧。
核心驱动力：
- 安全漏洞——弱算法（MD5、SHA-1）已被破解，弱密码（123456、admin）仍是常见入口
- 合规压力——等保2.0、国密算法落地要求、行业监管检查
- 业务风险——数据泄露导致用户流失、品牌信誉受损、法律诉讼
三个最常见的改造场景
我接手过的改造项目，十有八九是下面这三种情况。每个场景都有自己的脾气，咱们一个一个看。
1. 弱密码替换
老系统里密码存的是MD5甚至直接明文。我记得有个项目，客户说“我们密码存储没问题，用的是MD5加盐”。结果一看，盐是固定的字符串“salt”，跟没加一样。改造目标明确：换成bcrypt/argon2/scrypt这类抗暴力计算、自带盐的哈希函数，或者用国密SM3。
2. 加密算法升级
从RSA-1024升级到RSA-4096或国密SM2/SM4；从AES-128到AES-256；从SSL/TLS 1.1到TLS 1.3。这些升级往往涉及密钥长度的变化、协议握手流程的变化，兼容性是个大问题。我曾经在升级一个支付网关时，老客户端只支持TLS 1.1，升级后所有老客户端全部握手失败——还好有灰度回滚预案，没酿成大祸。
3. 多因素认证引入
以前一个密码走天下，现在要加上OTP、短信验证码、生物识别甚至硬件Key。引入MFA不仅仅是加个验证码验证的代码，还要改登录流程、会话管理、失败处理逻辑。而且用户习惯很难改——很多人第一次看到“请输入动态码”时直接打电话骂客服。
我个人经验： 这三种场景往往不是孤立发生的。一次认真的密码改造，通常同时涉及到弱密码替换 + 加密算法升级 + MFA引入。你最好在规划阶段就把它们当作一个整体去设计，分开改造反而容易增加耦合风险。
改造过程中的风险——我亲眼见过的翻车现场
改造不是写个补丁就完事。代码改了，还得考虑存量数据、对外接口、灰度切换。我把常见的风险列出来，全是拿真金白银换来的教训。
| 风险类型 | 具体场景 | 后果 |
|---|---|---|
| 数据不可逆 | 旧密码哈希被新哈希覆盖，但新算法验证失败，用户无法登录 | 用户账号全部锁死，客服被打爆 |
| 兼容性断裂 | 老客户端/第三方系统不支持新加密套件 | 集成调用失败，业务中断 |
| 性能突降 | bcrypt cost因子设太高，登录响应从50ms变成5s | 用户体验雪崩，DB连接池耗尽 |
| 回滚困难 | 改造完成后未保留旧密码备份或旧加密逻辑 | 出问题后无法快速恢复 |
| 阶段遗漏 | 只改了登录接口，没改密码重置接口、后台管理接口 | 攻击者仍可通过遗留入口绕过 |
我曾经踩过一次大坑： 某电商系统升级密码哈希，我手动写了迁移脚本，把旧MD5哈希全部转换为bcrypt再存回数据库。上线后发现有10%的用户密码验证永远失败。查了半天才发现——旧数据库里有一部分用户的密码是空字符串存入的，bcrypt处理空字符串会报错。从那以后，任何数据转换脚本我都强制加上边界值测试。
为什么容错是密码改造的必修课？
上面这些风险你回头看，每一个都跟“改坏了怎么办”挂钩。密码改造动的是认证体系的根基，一旦出错，用户进不来、数据取不了、业务直接停摆。所以容错机制不是锦上添花，而是保命底裤。
容错要解决三个核心问题：
- 改坏了能快速回滚——保留旧密码/旧算法代码，设计开关能一键切回旧逻辑
- 灰度验证能及时发现——先小范围用户试点，监控错误率、登录成功率、响应时间
- 改造过程不锁定用户——采用“双写+渐进迁移”模式，用户首次用新方式登录时就地更新，不要求全量数据一次性转换
说白了，你要给密码改造买一份“保险”。这份保险我习惯叫它回滚预案——后面的章节会展开讲具体怎么设计。
这张图其实是整个第1章的骨架：左边是推动改造的三股力量（为什么改），中间是三个最常见的改造场景（改什么），右边是改造过程中暴露的风险（改坏了会怎样），底部则指向唯一的出路——容错机制。后面的章节，我们就围绕“如何设计容错”展开，每一节都会对应一个具体的风险点或场景。