关键账号密码必须强制加密存储,禁用明文和MD5等弱算法,采用bcrypt或Argon2加盐慢哈希;服务端禁止解密,仅做比对验证;通过代码扫描、数据库审计、渗透测试三项硬控及DLP标记、脱敏运维、参数复核等管理措施保障落地。
关键账号密码必须加密存储,不是“可选”,而是强制性安全底线。明文或弱加密等于把门钥匙挂在门把手上。
用强哈希+盐值替代明文或MD5
数据库里绝不能出现明文密码,也禁止使用MD5、SHA-1等已被攻破的哈希算法。正确做法是:每个密码独立生成随机盐值,再用bcrypt或Argon2进行慢哈希处理。
- bcrypt自动内置盐值,支持调节计算强度(work factor),能有效拖慢暴力破解速度
- Argon2是当前NIST推荐标准,抗GPU/ASIC爆破,适合高敏感系统
- 每次注册或改密时重新生成新盐值,确保相同密码在库中哈希结果完全不同
服务端全程禁用解密能力
密码不是“需要还原”的数据,而是用于比对验证。因此系统设计上应彻底放弃“可逆加密”思路——不存密钥、不提供解密接口、不记录原始值。
- 登录时仅将用户输入经同样盐值和算法哈希后,与数据库存储值比对
- 重置密码只能走“新设流程”,而非“找回原密码”
- 日志、监控、调试输出中严禁打印、拼接、缓存原始密码字段
落地执行中的三个硬性控制点
光有技术方案不够,需嵌入开发、测试、上线全流程形成刚性约束。
- 代码扫描:CI/CD流水线中集成静态检测工具(如SonarQube规则),拦截bcrypt.gensalt()缺失、salt硬编码、明文赋值等风险代码
- 数据库审计:定期扫描user表、credential表,检查password字段是否为固定长度字符串(如60字符以上bcrypt输出),排除短哈希或明文特征
- 渗透验证:红队测试时,若能通过SQL注入获取password字段并直接登录,即判定机制失效,必须回溯整改
配套管理动作不能缺位
技术机制要有人盯、有责落、有据查,否则容易流于形式。
- 明确密码字段在数据字典中标记为“敏感字段”,纳入DLP策略统一识别和防护
- 运维变更操作(如备份导出、数据库迁移)必须启用脱敏模式,password字段默认替换为占位符
- 每年至少一次密钥与哈希参数复核:确认bcrypt work factor ≥12、Argon2内存参数≥64MB、迭代轮数≥3