📚 课程目录第3章密码迁移的核心挑战

密码迁移的核心挑战：数据一致性、安全传输、日志完整性

密码迁移这事儿，说白了就是个"脏活"。我做过好几次，每次都得捏把汗。你想想，几百万用户的密码如果搞砸了，那就不是小事故了。我归纳了一下，核心挑战无非三个：数据一致性、安全传输、日志完整性。今天我就把这几块的坑和经验摊开了说。

数据一致性——源和目标必须完全对齐

数据一致性，是我最先踩过的坑。我记得第一次做密码迁移，A系统用 SHA-256，B系统用 bcrypt，我天真地以为直接拷哈希就行。结果一大半用户登不上，为什么？因为哈希算法底层实现不一样，输出格式也不同。

这里边有个关键点：你要保证源端产生的所有密码数据，到了目标端之后——按同样的规则解读——得到完全相同的结果。什么情况下会出问题？我列几个：

哈希算法不同：比如 MD5 迁移到 bcrypt，必须重新哈希，不能在旧哈希上再盖一层。
编码问题：有的系统用 UTF-8，有的用 Latin-1，用户密码里含特殊字符就会炸。
盐值策略：老系统可能固定盐，新系统是随机盐，迁移后密码对不上。
截断行为：部分老系统哈希只保存前 8 位字符，新系统保存完整哈希，一对比就失败。

我的建议：迁移前一定要做批量"预校验"——同时在源端和目标端对同一条密码数据做相同运算，对比输出。我习惯写一个自动化脚本，跑完一轮直接出报告。

来看个简单的校验脚本：

import hashlib

def check_consistency(source_record, target_record, algorithm='sha256'):
    # 假设 source_record 是源端存的原哈希
    # target_record 是目标端算出的新哈希
    source_hash = source_record.strip()
    target_hash = target_record.strip()
    return source_hash == target_hash

# 批量跑一遍
with open('migration_log.csv') as f:
    for line in f:
        src, tgt = line.split(',')
        if not check_consistency(src, tgt):
            print(f'不一致记录: {src[:20]}...')

这段代码虽简单，但帮我在一个项目里逮到了 1300 多条不一致的记录，全是编码中间态造成的。你想想看，要是直接上线，这些用户就得天天找客服重置密码。

安全传输——不能被中间人"嗅探"

密码数据在传输过程中泄露，这几乎是所有安全人员的噩梦。我遇到过最离谱的一次，有个同事直接把密码哈希的 CSV 文件通过 HTTP 传到了目标服务器，结果被 IDS 抓了个正着。嗯，这是不该犯的错误。

核心原则很清晰：传输通道必须加密，身份必须验证。具体来说：

使用 TLS 1.2 或更高版本，证书要严格验证，不能跳过。
对敏感数据本身做一层 应用层加密，比如用 AES-256-GCM。这样即使 TLS 被打穿，数据也是密文。
使用 双向证书（mTLS），源端和目标端互相认证身份，防止伪造。

警告：千万不要为了省事，直接把密码数据丢到消息队列或公共对象存储上。我曾经见过一个团队，把迁移数据放进未加密的 S3 桶里，结果被人扫到了。还好数据量不大，不然就成大事故了。

实战中，我常用的传输包装是这样的：

import requests

def send_migration_batch(data, url, cert_path, key_path):
    # 使用客户端证书，强制 TLS
    response = requests.post(
        url,
        json=data,
        cert=(cert_path, key_path),
        verify=True,          # 验证服务端证书
        headers={'X-Batch-Id': 'batch-2025-03-01'}
    )
    response.raise_for_status()
    return response.json()

为什么还要额外加个 X-Batch-Id？这是用来做幂等性的，防止丢包后重复传输。你想想，如果网络断了重传，目标端收到两份数据，日志到底记哪份？所以幂等设计一定要有。

日志完整性——每一笔记录都要可审计

日志要是坏了，你连排查都查不了。我之前在一家金融机构做密码迁移，客户要求"所有操作日志必须不可篡改，留存 5 年"。他们是怎么做的？在每条日志末尾加了一个 HMAC 签名，密钥只有审计方持有。

日志完整的核心要求就三条：

每一条日志都不能丢：迁移过程中，每一笔操作（读、写、校验）都必须落盘。
写入后不能改：用哈希链或 HMAC 签名，保证改了一行就会全链断裂。
日志便于重建：记录的信息要足够详细，包括时间戳、源端标识、目标端标识、操作类型、结果状态、错误详情。

来看个日志结构示例：

字段	类型	说明
timestamp	ISO 8601	精确到毫秒
source_id	UUID	源端用户唯一标识
target_id	UUID	目标端用户唯一标识
operation	string	read / hash / verify / write
status	string	success / fail / retry
checksum	Hex	本行日志的 HMAC-SHA256 值

那这个 HMAC 怎么算？我习惯这样：

import hmac
import hashlib

def sign_log_entry(entry: str, secret: bytes) -> str:
    return hmac.new(
        secret,
        entry.encode('utf-8'),
        hashlib.sha256
    ).hexdigest()

每次写日志时，先把上一条的 checksum 也参与运算，形成哈希链。这样哪怕有人偷偷改了中间某一行的内容，后续所有行的 checksum 都会对不上。我曾经在一个项目里用这个办法，成功抓到了内部人员试图修改迁移失败记录的行为。嗯，有时候技术防线比制度管用。

记住：日志不只是为了出问题时甩锅，更是你事后复盘、持续改进的唯一一手资料。别等到数据丢了才后悔当初没记好日志。

下图总结了本章三个核心挑战的相互关系以及具体应对手段，你可以把它当成密码迁移的前置检查清单。

这三个挑战从来不是孤立的。数据一致性出了问题，日志里就得记下来；安全传输做不好，日志本身就是泄密渠道。所以实操时，我建议你把这三者当做一个整体来设计——别拆开了各做各的。