密码迁移概述：背景、场景与目标
聊密码迁移之前，我先问个问题：你手头有密码迁移的项目经验吗？
如果没有，别急。我做了这么多年安全架构，坦白讲，密码迁移这事儿看着简单，踩的坑还真不少。今天先把基础打牢——咱们聊聊为什么迁、迁到哪、迁成什么样。
密码迁移背景：为什么非要折腾？
说白了，密码迁移不是IT部门闲得慌。背后有几条硬杠杠：
- 安全合规逼着走 —— 等保2.0、GDPR、PCI-DSS，哪个都要求密码必须加盐哈希、不能明文存储、定期轮换。你原来的MD5散列表，不改行吗？不行。
- 算法老了撑不住 —— 我记得有个项目还在用SHA-1，我去看了直接喊停。破解成本越来越低，再不改就是给黑客送分。
- 平台换了 —— 企业上了云，本地AD用户要切到Azure AD、AWS Cognito或者自建IDP。旧密码库搬上去，不光是搬数据，整个认证链路都得重接。
- 用户体验被倒逼 —— 用户烦了天天重置密码。你想迁移完还能让用户原密码登录，这才是真本事。
核心矛盾：密码迁移最大的难点不是技术实现，而是“用户无感”。你迁完了，用户还得能用旧密码登录，hash算法却已经换了。这里头门道多着呢。
常见迁移场景：上云与换平台
我经手过的项目，九成以上落在这两类里。
场景一：上云迁移
本地AD或LDAP，要往云上IDP（比如Azure AD、AWS Cognito、阿里云IDaaS）搬。你想想看，本地密码用的是NTLM或Kerberos，云上用的是PBKDF2或bcrypt。直接搬hash？格式都不一样。
- 折中方案：双写模式。新密码入云旧密码留本地，用户登录时先查云，查不到再查本地，登录成功后异步迁移。嗯，这个我在几个银行项目里用过，效果不错。
- 硬核方案：用密码同步代理（Password Sync Agent），实时拦截密码变更推送到云端。不过网络抖动、延迟都得考虑。
场景二：换平台迁移
比如从Oracle IAM换到Keycloak，或者从自研密码系统迁到商业IDP。场景上云类似，但多了数据格式转换和业务对接。
- 坑：我曾经遇到一个客户，迁完用户登录时间暴涨3秒——因为新平台对bcrypt的work factor设得太高。你想想，10万用户同时登录，数据库直接打满。
- 避坑指南：迁移前先压测新平台密码验证的性能基线，work factor别盲目照搬推荐值，要根据并发量调低一点。
| 维度 | 上云迁移 | 换平台迁移 |
|---|---|---|
| 认证协议 | LDAP/Kerberos → OAuth2/OIDC | 私有API → 标准协议 |
| 密码存储 | NTLM哈希 → bcrypt/pbkdf2 | MD5/SHA1 → bcrypt/argon2 |
| 典型场景 | 本地AD迁Azure AD | Oracle IAM迁Keycloak |
| 主要风险 | 网络延迟、上云后的性能降级 | 协议不兼容、数据字段丢失 |
小技巧：无论哪种场景，我都会加一个“灰度迁移”开关：先迁5%的用户，跑一周观察告警日志和用户投诉，确认无误再全量。哪怕慢，也绝不能一把梭。
迁移目标：我们到底要迁成什么样？
目标有三个层次，我习惯称为“铁三角”：
- 零中断 —— 迁移过程中用户不能感知登录失败。这一点没得商量。
- 密码可验证 —— 旧密码在迁移后必须能用，且新hash算法能正确校验。这步需要设计“渐进式升级”逻辑：登录成功时自动将密码重哈希为新格式。
- 可审计可回滚 —— 迁移日志、告警阈值、失败重试策略都得提前配好。万一出事，一分钟内能切回旧系统。
警告：别信“强制重置密码可以省事”。用户强制重置会导致大量投诉和流失，尤其B2C场景。我见过一个电商平台迁完三个月用户投诉率翻倍——就是因为强制重置。后续花了半年才把信任拉回来。
为了让你直观理解密码迁移的全貌，我画了个框架图。这张图把背景、场景、目标串起来了，你一眼就能看清各部分之间的关系。
你仔细看这张图：背景、场景、目标天然是三层递进关系。我个人习惯把这三层先画在白板上，再开始设计具体的迁移方案。这样哪个环节缺了，一眼就能发现。
好了，第一张底图搭完了。接下来我们会深入到每个环节的具体玩法——告警阈值、流程设计、避坑……跟着我的节奏走，不会让你白读的。