密码迁移概述

说实话，密码迁移这事，接触过的人都知道——它就是一场“带着家当换房子”的活。

什么意思呢？就是把一批用户的密码凭证，从旧的存储系统（比如老数据库、本地 LDAP 或者自研认证模块），整体搬到新的密码管理体系里。我2018年帮一家金融公司做迁移时，他们用的还是MD5加固定盐……你想想看，当时《密码法》还没落地，但监管已经在敲警钟了。

迁移本身不难，难点在哪？日志。每一条密码操作都得留痕，不然审计来了你解释不清。

什么是密码迁移

密码迁移，说白了就是把用户的认证凭据——通常是哈希后的密码、盐值、算法标识——从A系统复制到B系统，还要保证迁移后用户能用原来的密码正常登录。

我在项目里见过一个常见误区：有人直接把数据库里的密码字段复制过去，结果新系统用的哈希算法不同，用户一登录就失败。嗯，后来挨个帮用户重置密码，那叫一个惨。

密码迁移通常涉及这几个动作：

• 解密或导出：从旧系统安全读取密码记录
• 格式转换：把旧哈希转为新系统支持的格式（比如从MD5转为bcrypt）
• 数据清洗：去掉过期账户、重复项、异常记录
• 批量写入：向新密码存储写入数据，同时生成迁移日志
• 验证：随机抽检迁移后的用户能否正常认证

这里我特别想强调一个点：迁移不是拷贝，是“转换+验证”。我曾经遇到一个团队，直接把旧系统的SHA-1哈希塞进新系统的字段里，新系统没做任何校验，结果上线后30%的用户无法登录——因为新旧两个系统的密码策略（复杂度、长度上限）根本不一样。

典型迁移场景

为什么需要日志合规性

你可能会问：我老老实实做迁移，为什么非要把日志搞得那么复杂？

原因就三个字：可追溯。审计来了，你得能说明谁、在什么时间、用什么工具、迁移了多少条记录、有没有异常失败。这些信息必须通过日志完整保留，否则就算合规违规。

我个人习惯把日志合规性拆成四个维度：

1. 完整性：每条迁移操作都要记录，不能丢
2. 不可篡改：日志写入后不能被修改或删除（比如使用append-only存储）
3. 可读性：日志内容能被人和机器理解，字段固定
4. 时效性：日志产生后进入归档系统的时间不能超过N小时（通常24小时内）

我在一个银行项目中经历过一次合规检查。对方审计直接要求提供迁移期间所有密码操作的日志，包括“读、写、删、改”每一步。幸好我们当时用了结构化的JSON日志，每条都包含用户标识、操作类型、时间戳、执行账号、结果状态。审计人员只看了5分钟就说“没问题”。你想想看，如果那时候我们只打了几个info/debug级别的字，估计得补数个月的证据。

密码迁移与日志合规的落地关系

说白了，密码迁移是一个高风险操作，日志合规是那道安。没有合规日志，迁移出了问题（比如数据丢失、泄露）你根本没法定位根因，更扛不住监管的质询。

我建议在每个迁移步骤中都嵌入日志埋点，而不是迁移完成后统一补打。比如：

# 伪代码示例：迁移过程中的日志记录
def migrate_password(user_id, old_hash, new_hash):
    log_event("PASSWORD_MIGRATE_START", {"user_id": user_id, "old_algorithm": detect_algorithm(old_hash)})
    try:
        new_record = convert_and_store(user_id, old_hash, new_hash)
        log_event("PASSWORD_MIGRATE_SUCCESS", {"user_id": user_id, "new_algorithm": new_record.algorithm})
    except Exception as e:
        log_event("PASSWORD_MIGRATE_FAIL", {"user_id": user_id, "error": str(e)})
        raise

这样每一笔操作都有完整的“开始-成功/失败”记录。我曾经接手过一个遗留项目，迁移日志只记了“完成数量”，完全没有单条记录轨迹。后来用户投诉说密码不对，我们花了三周才排查出来是因为某个旧系统使用了不同的字符编码。

知识体系一览

为了帮你理清思路，我把本章的核心知识点画成了一张图。整个密码迁移与日志合规的关系，其实就是下面这几个环节串起来的：

好了，这章我们先聊到这里。记住：迁移之前，先想好日志怎么打。