第1章：密码迁移概述

1.1 背景：为什么需要密码迁移？

先聊点实际的。你想想看，一个系统用了好几年，密码都是明文存储——能忍吗？不能忍。但我见过太多团队，总觉得“能用就别动”，结果一次数据泄露，裸奔。

我入行那会儿，一家金融机构的遗留系统用的还是 MD5，连盐都没加。我当时的任务是把它整体迁移到 bcrypt。为什么？因为合规审计来了，一句“密码存储不符合 PCI-DSS 要求”，整个部门就得加班三个月。说白了，密码迁移的根源无非三类：

• 安全升级：从弱哈希（MD5、SHA-1）换成强哈希（bcrypt、argon2）。
• 架构变更：从自建 LDAP 迁移到云 IAM，或者从单库拆成多租户。
• 合规驱动：等保、GDPR、SOC2 要求你留下完整的密码变更痕迹。

嗯，这里要注意：迁移从来不是简单的“复制粘贴”，密码这东西，平迁等于没迁。

1.2 目标：迁移后要达成什么？

目标很好写，但落地很骨感。我一般会跟团队定三个硬指标：

目标维度	具体说明	我的踩坑点
安全提升	密码存储算法升级，加盐、迭代次数达标	有次迭代次数设太低，秒破……
可审计性	每个密码操作都有完整日志链	日志字段丢了 salt，追溯不了
业务零中断	迁移期间用户无感登录	混合验证期必须保留旧哈希

你可能会问，为什么审计日志这么重要？举个例子：迁移完成后如果出现密码校验失败，没有日志，你连是算法不兼容还是盐值丢失都不知道。我遇到过一回，客户坚持“先迁再补日志”，后来出了事故，查了三天才定位到是哈希字段长度截断。所以我的原则是——审计字段设计必须在迁移脚本之前敲定。

1.3 适用范围：企业常见场景

不是所有系统都需要同样的迁移方案。你想想，一个亿级用户平台和一个内部 OA 能一样吗？我一般按复杂度分三类：

• 轻量级：单体应用，用户数 < 10 万，密码字段简单。直接切换即可。
• 中大型：多数据源、混合认证（LDAP + 数据库）。需要灰度迁移、双写验证。
• 超大规模：全球多活、密码分片。这时候审计日志字段必须包含节点 ID、时间戳精度到毫秒级。

我记得有个项目，团队把所有用户的密码一次性重哈希，结果登录高峰期数据库被打爆。从那以后，我坚持用“按用户活跃度分批迁移”的策略。

1.4 核心挑战：迁移中的常见陷阱

我不喜欢把挑战列成理论清单，直接说实际项目中反复出现的坑吧：

1. 算法不兼容：旧系统用 bcrypt（60 字符），新系统用 argon2，字段长度不一致。我见过直接截断的，后果是密码永远验证不过。
2. 盐值丢失：迁移时忘了导出 salt 字段。你想想，没盐的哈希跟明文有多大区别？
3. 日志断层：迁移前审计日志只记录了“登录成功/失败”，迁移后增加了“密码算法版本、盐值、迭代次数”。新旧字段不统一，分析工具直接报错。
4. 回滚欠缺：一旦迁移失败，没有日志记录“哪些用户已经迁移过了”，只能全量回滚。

所以，密码迁移的核心挑战，表面上是算法和存储，实际上全落在审计日志字段的设计上。字段少一个，排查多一天。

1.5 核心流程图：密码迁移审计日志上下文

下面是我自己画的一张草图，把迁移流程和审计日志生成点串在一起。你大概看一眼就行，后续章节会逐层拆解。

图上几个关键节点，我稍微解释一下：

• 旧密码库→迁移引擎：这一步最容易丢失 salt 字段，审计日志必须记录“从旧库取出了哪些字段”。
• 迁移引擎→新密码库：这里会生成新盐值、新哈希，日志里要记录算法版本（比如 bcrypt v2a、argon2id）。
• 认证平台：混合验证期间，用户登录时可能走旧算法也可能走新算法。日志字段必须包含“本次使用的算法标识”。
• 审计日志系统：最终所有字段归一化，形成统一的审计记录。

说白了，这张图就是咱们这本教程的地图。后面的每一章，几乎都会落到图上的某个点上——字段变化、算法对比、时间戳精度、回滚标签……一个个拆。