密码怎么存才安全：加盐哈希、bcrypt / Argon2 与泄露后的补救顺序

约 7 分钟读完 · 更新于 2026-10-21 · 文中每条都能在下面的配套工具里动手验证

结论先行：只有「慢哈希 + 随机盐」这一条路

密码存 MD5、SHA-1、单次 SHA-256，甚至「SHA-256 加一个固定后缀」，在拿到数据库的人面前和明文差别不大——彩虹表能直接查，GPU 每秒能试几十亿次。正确方向只有一个：bcrypt / scrypt / Argon2id 这类刻意设计得慢的哈希，每个密码配独立随机盐，把耗时参数（cost）写进存储格式里，以便以后调高而不动数据结构。

算法对照：能干什么，能不能存密码

加盐解决了什么，没解决什么

salt 是每个密码单独生成的随机串（至少 16 字节），作用是让相同密码的哈希值各不相同，彩虹表因此彻底失效。但它挡不住另一种攻击：攻击者拿到哈希后离线猜。哈希函数越快，猜得越快——单张高端 GPU 每秒几十亿次 SHA-256，纯 8 位数字密码的一亿种组合几秒就穷举完了。补上这一段要靠慢哈希：bcrypt 的 cost 每加 1 耗时翻倍，Argon2 直接调内存和迭代次数。目标不是让哈希"看着乱"，而是让攻击者的单位成本高到不划算。

const row = db.query("SELECT pw_md5 FROM users WHERE email = ?", [email]);
if (row.pw_md5 === md5(password)) { /* 不该走到这里 */ }

// 同样危险：所有用户共用一个固定盐，等于没加盐
const bad = sha256(password + "2024salt");

const bcrypt = require("bcrypt");

// cost=12：同一台机上单次校验约 200-400ms，按自己的 P99 预算调
const hash = await bcrypt.hash(password, 12);
// -> "$2b$12$LQv3c1yqBWVHxkd0LHAkCOYz6TtxMQJqhN8/LewYfCz7c5X1MSky"

const ok = await bcrypt.compare(password, hash); // 唯一正确的校验方式

const argon2 = require("argon2");
const argonHash = await argon2.hash(password, {
  type: argon2.argon2id,
  memoryCost: 19456,  // KiB，约 19MiB
  timeCost: 2,
  parallelism: 1,
});
// 库名、版本、参数、随机盐全部随哈希一起返回，无需额外字段

const crypto = require("crypto");

function safeEqualHex(a, b) {
  const ba = Buffer.from(a, "hex"), bb = Buffer.from(b, "hex");
  return ba.length === bb.length && crypto.timingSafeEqual(ba, bb);
}
// 直接 a === b 会在第一个不同的字节处提前返回，理论上可被逐字节试探

落地七步，按顺序做

1. 选算法：原生支持就上 Argon2id；语言库成熟度优先时用 bcrypt；合规强制 FIPS 才退到 PBKDF2-HMAC-SHA256。
2. 定 cost：以「单次校验 100-250ms」为靶子压测。bcrypt 从 10 起，硬件变强就往上调；线上超过 500ms 会把登录 QPS 拖垮。
3. 生成盐：每个密码用密码学安全随机源取 16 字节以上。bcrypt / Argon2 会把盐打包进哈希串，数据库里不需要单独的 salt 列。
4. 存整串：连算法标识和参数一起存（$2b$12$…、$argon2id$v=19$…）。只存裸哈希值就永远升不了 cost。
5. 只走 compare / verify：绝不要把哈希取出来用 == 比，也不要写进日志、错误信息、埋点和监控。
6. 留升级路径：把 cost 做成配置项；登录成功后判断存量哈希的 cost 是否低于当前值，低于就重新哈希并落库。
7. 考虑 pepper：再混入一个只存在 KMS 或环境变量、绝不进数据库的密钥。数据库被脱库时，单靠哈希无法离线爆破；代价是轮换 pepper 会要求全站重新登录与重哈希。

cost 参数怎么定：看耗时，不看数字

六个反复出现的错误做法

• 认为「加个 salt 就行」，继续用 MD5 或单次 SHA-256 存密码。
• salt 写死成一个字符串常量，所有用户共用——等于没加。
• 用 Math.random() 生成 salt，或拿时间戳、用户 ID 代替随机值：全都能被预测出来。
• 把哈希写进日志、链路追踪和错误上报，监控系统本身成了新的泄露源。
• 拿哈希当用户唯一标识，或为省空间截断成 8 位十六进制：前者泄露影响面扩大，后者直接降强度。
• 强制用户每 90 天改密。逼出来的结果是 a1B2c3 这种规律密码；现代做法是长度优先（至少 12 位）、拦截常见密码字典、检测泄露库命中。
• 自研算法，或把「MD5 之后再加盐」当 bcrypt 用：多一层不增加安全性，只增加迁移成本。

数据库已经泄露了：按这个顺序补救

先算清泄露面，再止血。第一步确认范围：dump 出来的表里有没有明文列——很多老系统同时留着 password 和 pw_hash 两列，只看哈希列会漏。第二步按存储方式分支：明文或无盐哈希视同全部已破，立刻全站强制改密、失效所有会话、关闭邮件找回通道（攻击者会比你先改邮箱）。第三步若存的是加盐哈希，不要一上来就全员改密：先加 pepper、把 cost 提到当前标准，让攻击者的离线批量破解成本抬高，再分批改密，避免整改动作本身把服务打挂。第四步补配套：MFA、登录失败限流、异常 IP 与新设备登录告警。第五步把密码存储与升级策略写进代码规范和安全评审清单，不要只在复盘纪要里写一句「以后注意」。

密码强度该看什么：熵，不是复杂度规则

「必须含大小写 + 数字 + 符号」这类规则只会把用户推向 P@ssw0rd1 这种可预测组合。评估强度看三件事：长度（12 位以上是当前性价比最高的手段）、熵值（字符集大小与长度共同决定随机性）、以及是否落在常见密码字典里。熵低不代表这个密码一定被秒破，但字典攻击的成本几乎只取决于它在字典里的位置。注册和改密时先做一次本地强度评估，比事后靠规则打回重填的转化率好得多。

常见问题