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

你想想看，一个系统跑了好几年，密码这东西，基本都是「能用就行」。没人会主动去翻那些配置文件，也没人管它是不是加密的。可一旦出问题，往往就是大问题。

我经历过一个项目，线上有个老模块，密码直接明文写在配置文件里。运维小哥说「一直这样啊，没出过事」。直到某天安全扫描扫出来，公司被通报，CTO 连夜拉我们开会。嗯，那时候我才意识到，密码迁移不是「要不要做」，而是「什么时候做」的问题。

存量密码：你根本不知道有多少坑

存量密码是什么？就是那些已经存在、正在运行的密码。它们藏在各个角落里：

• 配置文件：application.properties、config.yml、.env……
• 环境变量：Docker 启动参数、K8s Secrets（但 Secret 本身也是明文 base64）
• 数据库表：用户表里存的密码，可能是 MD5、SHA1，甚至是明文
• 硬编码：代码里直接写死了连接串，比如 jdbc:mysql://localhost:3306/db?user=root&password=123456
• 第三方依赖：某些 SDK 默认密码，或者测试账号忘了删

我记得在梳理存量密码时，发现一个十年老系统里，密码用的还是 DES 加密。DES 啊，连 2005 年的显卡都能秒破。你说危不危险？

为什么要迁移？三个核心原因

维度	现状	迁移后的目标
安全	弱加密、明文、硬编码、共享密码	强加密（如 bcrypt）、密钥独立、最低权限
合规	不满足等保、GDPR、PCI-DSS 要求	满足密码存储、传输、轮换审计要求
运维	密码过期没人管、变更靠人肉、故障恢复难	自动轮换、密钥集中管理、可审计可追溯

说白了，密码迁移就是一次「债务清理」。你不清，利息会越来越高。

存量密码梳理流程

我个人习惯分四步走：

1. 发现：扫描所有配置源、代码仓库、数据库连接池、配置文件环境。
2. 分类：按来源（配置文件/代码/数据库/环境变量）和加密等级（明文/MD5/SHA/强加密）打标。
3. 评估：每类密码目前的风险评级，比如「明文+外网可达」就是高危。
4. 排序：优先处理高危项，再处理中低危。

风险分析：到底有什么风险？

我遇到过的典型问题：

• 明文泄露：配置仓库如果被外部访问，所有密码等于裸奔。我在一个项目中见过 .git 泄露，攻击者直接下载了生产数据库连接串。
• 密码复用：开发、测试、生产用同一套密码。一旦开发环境被入侵，生产也完蛋。
• 未及时轮换：一个支付服务密钥三年没换，离职员工手里还有备份。你说慌不慌？
• 弱加密算法：MD5 用于登录密码存储？我拿个彩虹表几秒钟就破了。
• 错误管理：没有密码过期策略，没有密钥备份机制。某次硬盘故障，密码丢失，恢复业务花了两天。

迁移前必须回答的问题

在做密码迁移之前，我建议团队先确认这几点：

• 当前密码的存储位置你全知道吗？——画一张 密码资产地图。
• 密码的消费方有哪些？——哪个服务、哪个模块、哪个定时任务用了它？
• 有没有共享密码？——多个系统用同一个密码，迁移一个会影响其他。
• 有没有灰度验证能力？——改完密码后可以先在小流量环境测试。
• 回滚方案是什么？——万一改了之后系统连不上，能迅速切回旧密码。

这些问题，都是我在实践中踩过坑后总结出来的。一开始我跳过了「密码资产地图」这一步，结果改了十几个密码后发现还有两个服务没改，线上出了故障。后来我学乖了，先把所有密码列成一个表，标清楚「谁在用」「加密等级」「是否共享」「最后修改时间」。

上面这个图，是我在项目里用它来跟团队对齐思路的。从梳理存量密码开始，到风险评级，再到判断是否安全达标——大多数存量系统都会进入「不达标 -> 制定迁移计划 -> 灰度实施」这条路线。你需要做的，就是把这一步走扎实。

我的建议：从「静默迁移」开始

不是所有的密码迁移都需要停机。我很推崇一种做法叫「静默迁移」：先在新系统里同时支持新旧两套密码，然后逐步切流，最后废除旧的。整个过程对用户无感。

比如登录密码迁移：用户登录时，先按新算法验证，如果不通过，再按旧算法验证，同时触发异步更新密码为新算法。下次登录就自动走新算法了。我在一个千万级用户的项目里用过，效果不错。