1. 密码改造概述
密码改造这个话题，说白了就是给你的系统换一把更安全的锁。我这些年做安全审计，见过太多因为密码算法老旧而被攻破的案例。有一次，一家金融客户的内部平台还在用 MD5 存储用户密码，结果撞库攻击直接拿走了几十万条记录……嗯，那场面可不太好看。
这一章我们就聊聊为什么非得改造、改造要达成什么目标、范围划到哪、以及到底能收获什么。我不扯虚的，都是实际踩坑后的总结。
1.1 改造背景
背景其实就三股力量推着你不得不改：
- 政策合规：《密码法》2020 年生效，等保 2.0 明确要求使用国密算法（SM2/SM3/SM4/SM9）。不满足，就过不了等保测评，也拿不到合规资质。
- 旧算法风险：MD5、SHA-1 已经被证明存在碰撞攻击，3DES、RSA-1024 的密钥长度不够，AES-ECB 模式有模式泄露问题。我曾在项目里见过用 3DES 加密传输的接口，爆破时间只要半小时。
- 业务安全需求：内部开发者平台承载着 CI/CD 流水线、代码仓库、制品库、密钥管理等核心资产。一旦密码被突破，整个交付链都会沦陷。
一句话总结：密码改造不是为了应付检查，而是为了降低企业整体风险敞口。我在构建内部开发者平台时，第一件事就是审查所有密码算法调用点。
1.2 改造目标
改造目标不能只写“使用国密”，那样太模糊。我建议拆成三个可量化的维度：
| 目标维度 | 具体指标 | 验收方式 |
|---|---|---|
| 合规性 | 所有加解密操作使用国密算法（SM2/SM3/SM4/SM9） | 第三方合规审计报告 |
| 安全性 | 消除 SHA-1、MD5、3DES、RSA-1024 等弱算法 | 自动化扫描工具配合人工复核 |
| 可用性 | 改造后性能损耗不超过原算法 5%，接口响应时间无劣化 | 压测报告 + 监控曲线对比 |
你想想看，如果改造完却导致平台响应从 20ms 变成 200ms，那开发者肯定会骂娘。所以性能目标必须和合规目标放在同等位置。
1.3 改造范围
范围划定这件事我踩过坑。一开始只想改认证模块，结果发现日志、数据库、消息队列、甚至 CI/CD 的构建产物签名都用到了旧算法。范围画小了，改造完仍然是漏勺。
我建议按“层”来划分：
- 应用层：用户密码存储、会话令牌签名、API 请求验签、代码签名。
- 传输层：TLS 证书密钥协商（改为 SM2 证书）、内部 gRPC 通道加密。
- 存储层：数据库字段加密（如个人敏感信息）、制品库文件加密、备份加密。
- 密钥管理层：根密钥生成、密钥轮换策略、硬件安全模块（HSM）对接。
- 集成点：LDAP/OAuth 认证集成、外部供应商 API 加密对接。
曾经踩过的坑：一次改造中我漏掉了构建镜像的签名算法，结果镜像被篡改后直接部署到生产环境。所以范围划定时，一定要覆盖“全生命周期”——从代码提交到制品投产。
1.4 预期收益
收益不是虚的，我亲手算过两笔账：
- 合规通过：改造后等保测评一次性通过，省去反复整改的人力成本（约 3-4 人月）。
- 安全风险降低：消除因弱算法导致的数据泄露风险，避免一次安全事件平均 500 万的损失。
- 性能提升：国密 SM4 在硬件加速下，加解密速度比旧版 3DES 快 8-10 倍。我在某平台实测过，SM4 软实现也比 3DES 快 2 倍。
- 统一密码基座：改造后所有业务调用统一密码 SDK，不用再维护五花八门的算法实现，开发效率提升 20%。
我的建议：改造初期不要追求一步到位。先给所有调用点打上“算法标签”，优先替换“高危”（如 MD5、SHA-1），再逐步替换“中危”（如 RSA-1024、AES-ECB）。
老实说，密码改造不是一次性工程。内部开发者平台涉及的集成点太多，改起来就像给飞行中的飞机换引擎。但只要你把背景看透、目标定死、范围划全、收益算清，后续的推进就顺了。