$pbkdf2-sha256$i=600000,l=32$盐$哈希),会自动解析出全部参数;否则沿用左侧参数面板的当前设置。PBKDF2 密钥派生与校验工具,分为两个面板:
$pbkdf2-sha256$i=600000,l=32$盐$哈希)。所有计算都在浏览器本机完成,密码与哈希值都不会上传到服务器。
PBKDF2-HMAC-SHA256。PBKDF2(Password-Based Key Derivation Function 2)由 RSA Laboratories 设计,最初发布于 PKCS #5 v2.0(RFC 2898),现行版本为 RFC 8018,同时被 NIST SP 800-132 采纳。
| 项目 | 说明 |
|---|---|
| 发布年份 | 2000(RFC 2898),2017(RFC 8018) |
| 设计机构 | RSA Laboratories |
| 底层结构 | HMAC 迭代(HMAC-SHA1 / SHA256 / SHA512 等) |
| 标准 | RFC 8018、NIST SP 800-132 |
| 盐长度 | 建议至少 16 字节 |
| 是否可逆 | 不可逆 |
| FIPS 合规 | 是 |
PBKDF2 的公式可以简写为:
DK = T_1 || T_2 || ... || T_l
T_i = F(P, S, c, i)
F(P, S, c, i) = U_1 XOR U_2 XOR ... XOR U_c
U_1 = HMAC(P, S || INT(i))
U_j = HMAC(P, U_{j-1})
其中 P 是密码,S 是盐,c 是迭代次数,l 是输出块数。核心思想很简单:把 HMAC 反复迭代 c 次,让每次尝试都付出 c 倍的计算代价。
迭代次数是 PBKDF2 唯一的安全旋钮,次数越高越难暴力破解,但用户等待也越久。
| 来源 | 算法 | 建议迭代次数 | 本机参考耗时 |
|---|---|---|---|
| OWASP(2023) | HMAC-SHA1 | 1300000 | 约 3.5 s |
| OWASP(2023) | HMAC-SHA256 | 600000 | 约 1.6 s |
| OWASP(2023) | HMAC-SHA512 | 210000 | 约 0.7 s |
| 快速预览 | HMAC-SHA256 | 100000 | 约 0.27 s |
| 旧系统常见 | HMAC-SHA1 | 1000 – 10000 | 约 3 – 30 ms |
原则仍然是:让单次校验耗时落在 100 – 500 毫秒之间。OWASP 给的是 2023 年的建议值,实际部署时应按服务器算力实测调整。
这是 PBKDF2 与其他口令哈希最大的差别:
因此实际系统里通常会自己拼一个存储格式,常见的有:
| 格式 | 示例 | 来源 |
|---|---|---|
| PHC 字符串 | $pbkdf2-sha256$i=600000,l=32$<盐b64>$<哈希b64> | PHC 规范 |
| passlib | $pbkdf2-sha256$29000$<盐>$<哈希> | Python passlib |
| Django | pbkdf2_sha256$600000$<盐>$<哈希> | Django |
本工具的校验面板支持直接粘贴 PHC 串并自动解析全部参数,其他格式需要手动把参数填到左侧面板。
| 场景 | 是否适合 |
|---|---|
| 必须满足 FIPS 140 合规 | 适合。PBKDF2 是 NIST 认可的算法,Argon2 与 Bcrypt 都不符合 |
| 对接只支持 PBKDF2 的旧系统 | 适合 |
| 环境算力与内存受限(如嵌入式、HSM) | 适合,只需 CPU 时间不占内存 |
| 新项目的通用口令存储 | 可以,但优先 Argon2id;PBKDF2 抗 GPU 能力较弱 |
| 从密码派生加密密钥(而非口令存储) | 适合,这是它的原始设计用途 |
| 格式 | 说明 |
|---|---|
| 十六进制 | 默认输出,最通用 |
| PHC 格式 | 把算法、迭代、长度、盐、哈希拼成自描述串,便于存储与迁移 |
同一个密码每次生成的 PBKDF2 哈希一样吗?
PBKDF2 可以用来加密文件吗?
盐值需要多长?
密码和哈希值会被上传到服务器吗?
改了迭代次数,之前存的哈希还能校验吗?
为什么默认迭代次数是 600000,算起来有点慢?
PBKDF2 符合 FIPS 140 认证吗?
PBKDF2 和 Bcrypt、Argon2 该选哪个?
PHC 串是什么?为什么要用它?
为什么校验时还要填算法和迭代次数?
迭代次数应该设多少?
PBKDF2 是什么?