口令存储怎么选
口令存储的目标是让攻击者拿到数据库后也无法低成本还原口令：必须使用带盐、故意变慢的抗暴力破解算法，并设计参数升级路径。现代方案可在 Argon2id、scrypt、bcrypt 与 PBKDF2 之间按环境与合规要求选择；明文存储、可逆加密或单轮哈希都不满足基本要求。
基本信息
| 首选方案 | Argon2id（RFC 9106） |
|---|---|
| 备选方案 | scrypt（RFC 7914）、bcrypt、PBKDF2（合规场景常见） |
| 必要属性 | 每用户唯一盐、可配置工作因子、算法与参数随散列存储 |
| 禁止做法 | 明文、可逆加密、单轮 MD5/SHA-1/SHA-256 |
| 迁移方式 | 登录成功后按新参数重算并覆盖，渐进式升级 |
| 识别方式 | 散列前缀，如 $argon2id$、$2b$、$5$、$6$ |
典型使用场景
- 新系统建库：直接采用 Argon2id 并实测可用参数
- 老系统整改：把 MD5、SHA-1 或极低迭代 PBKDF2 存量升级
- 合规自查：等保与行业规范对口令存储有明确要求
- 多系统统一：内部多个应用统一算法与参数，降低维护成本
- 审计取证：判断现有存储方案是否具备抗离线爆破能力
渐进式升级思路（伪代码）
渐进式升级思路（伪代码）
login(user, pw):
h = load_hash(user) # 散列中带算法与参数
if not verify(pw, h): return fail # 校验失败统一返回
if is_legacy(h) or needs_rehash(h): # 老算法或参数低于当前标准
store_hash(user, hash(pw)) # 用新参数重算并覆盖
return ok
# 特点：用户无需改密，迁移随登录自然完成，可长期运行方案对照
| 方案 | 抗 GPU 能力 | 关键参数 | 备注 |
|---|---|---|---|
| Argon2id | 强 | 内存与迭代可调，如 19-46 MiB 配 1-2 次迭代 | 新项目优先 |
| scrypt | 强 | N、r、p 三个参数需同时评估 | 库支持情况需确认 |
| bcrypt | 中 | cost 10 及以上 | 输入长度上限 72 字节 |
| PBKDF2 | 中偏弱 | SHA-256 迭代次数按当前建议设置 | 合规场景常见 |
| 单轮 SHA-256 或 MD5 | 无 | - | 不可用于口令存储 |
迁移依赖散列前缀识别算法：老系统的 $1$（MD5-crypt）、$2b$（bcrypt）、$5$/$6$（SHA-256/512-crypt）与新系统的 $argon2id$ 需要能同时校验。保留旧算法标识，才能实现「老用户照常登录、登录后自动升级」。
不要用「加固定前缀或加固定盐」冒充安全增强：固定值可读即无秘密，真正的防护来自算法选择与参数强度。同时警惕把口令加密后存库的做法，密钥泄漏即可批量还原口令。