马上默 在线轻量工具箱
登录
🔑 派生过程在你自己的浏览器里完成，用的是浏览器内置的 Web Crypto。口令不会上传、不会被记录。请不要在这里输入你正在使用的真实口令，用测试口令即可。

🔑 PBKDF2 派生

0 字节

Salt 必须每个用户都不同且随机生成，它让彩虹表彻底失效。存密文时把 salt 一起存（它不需要保密）。

迭代次数越高越难破解，代价是每次派生都要多花时间。OWASP 对 PBKDF2-SHA256 的建议是 60 万次。

📤 派生结果

0 字符
耗时 —
输出长度 —
单次成本 —
相对 10 万次 —
填好参数后评估

📊 迭代次数怎么定

以 PBKDF2-SHA256 为例，耗时是单核现代浏览器的粗略参考。

迭代次数典型耗时相对成本评价
1 万约 10 ms0.1×❌ 太低，仅适合极低性能设备
10 万约 100 ms1×⚠️ 兼容底线，不建议新系统采用
31 万约 300 ms3.1×✅ 实用平衡点
60 万约 600 ms6×✅ OWASP 推荐下限
100 万约 1 s10×✅ 更硬，登录会略有感知
500 万约 5 s50×⚠️ 太慢，影响体验，不如换算法

⚠️ 使用提示：① 不要在这里输入你正在使用的真实口令——本工具用于学习与验证参数，请用测试口令；② PBKDF2 只是减慢破解速度，挡不住弱口令：`123456` 配 100 万次迭代依然秒破，口令强度永远是第一位；③ 本工具是可调参数的演示器，不是密码存储方案——生产环境请使用成熟库（Argon2id / bcrypt / scrypt）并把参数写进代码，不要手工拼接；④ Web Crypto 没有 Argon2，如果需要 Argon2id 请在服务端用专业库实现；⑤ 迭代次数要和 salt、结果一起存储，否则以后无法复现同样的派生结果；⑥ 本工具不保存任何输入，刷新即清空。

🔑

PBKDF2 口令派生

加密工具 完全免费 🌙 支持黑夜模式 🔒 本地计算，不上传 🎲 随机 Salt 📊 强度评估

「把用户口令安全地存起来」这件事，第一步就是把口令派生成一串不可逆的密钥——PBKDF2 就是干这个的。
很多人只听说过它，但从没直观感受过参数的影响。这个工具让它变得可观察：
① 参数全可调：哈希算法、salt、迭代次数、输出长度，一个不落；
② 耗时实时显示：把迭代次数从 10 万调到 100 万，你会亲眼看到时间从 0.1 秒变成 1 秒——这就是「让破解变慢」的实际代价；
③ 相对成本：以 10 万次为基准，告诉你当前配置是几倍；
④ 强度评估条：把迭代次数和哈希算法综合成一个直观的评分，配 SHA-1 会被扣分；
⑤ 随机 salt 一键生成：用密码学安全的随机数，不是 `Math.random()`。
全程在你自己的浏览器里完成，口令不上传、不记录，刷新就没了。

类别加密工具
算法PBKDF2（SHA-1 / 256 / 384 / 512）
输出128 / 192 / 256 / 512 位
运行环境需 HTTPS 或 localhost

核心特性

原生 Web Crypto
四种哈希
自定义 Salt
迭代次数可调
128~512 位输出
耗时实测
强度评估条
不上传

关于这个工具

怎么实现：
① 导入：`crypto.subtle.importKey('raw', 口令字节, 'PBKDF2', false, ['deriveBits'])`；
② 派生：`crypto.subtle.deriveBits({ name: 'PBKDF2', salt, iterations, hash }, key, 位数)`。口令先用 `TextEncoder` 转成 UTF-8 字节，保证中文口令也按字节正确参与；
③ 随机 salt：`crypto.getRandomValues()` 生成 16 字节（128 位），来自系统 CSPRNG；
④ 耗时测量：用 `performance.now()` 包住完整的 importKey + deriveBits，反映真实开销（含一次性的密钥导入）；
⑤ 强度评估：按迭代次数分档打分（1 万以下 10 分，10 万 35 分，31 万 60 分，60 万 80 分，100 万以上 95 分），使用 SHA-1 时上限压到 50 分；这只是参数强度，不代表口令强度。
它不做：不做口令强度检测、不做 Argon2 / bcrypt / scrypt（Web Crypto 里没有）、不做密码库与存储。

怎么用

  1. 第 1 步
    输入一个测试口令（别用真实口令），点「🎲 随机 16 字节」生成 salt。
  2. 第 2 步
    哈希选 SHA-256，位数选 256，迭代次数先设 31 万。
  3. 第 3 步
    点「🔑 开始派生」，看耗时。
  4. 第 4 步
    把迭代次数改成 10 万、60 万、100 万各算一次，感受耗时与「相对成本」的变化。
  5. 第 5 步
    确认同一组参数（口令 + salt + 迭代 + 位数）每次结果都完全一致——这是它能用于校验的前提。

更新记录

  • v1.0 2026-09-21 工具正式上线：基于浏览器原生 Web Crypto（importKey + deriveBits）实现 PBKDF2 口令派生，支持 SHA-1 / 256 / 384 / 512、自定义 salt（可一键随机 16 字节）、迭代次数可调（含 10 万 / 31 万 / 60 万 / 100 万 快捷档）与 128~512 位输出；实时显示实测耗时、相对 10 万次的成本倍数与强度评估条（SHA-1 会扣分）；输出 Hex / Base64。非安全上下文给出明确引导。纯本地零依赖，适配黑夜模式。

常见问题

为什么不能直接用 SHA-256(password) 存密码？
因为普通哈希太快了。
一块消费级显卡每秒能算几十亿次 SHA-256，配合彩虹表和常见口令字典，绝大多数用户的密码会在几秒内被还原。
PBKDF2 的做法是把哈希重复很多次（几十万次），让单次计算从「纳秒级」变成「百毫秒级」——对你来说登录慢一点点，对攻击者来说成本放大几十万倍。
现代更推荐 Argon2id（还能抗 GPU/ASIC），但 PBKDF2 兼容性最好，且是 NIST 认可的算法。
Salt 为什么要随机、要每个用户不同？
两个作用：
① 废掉彩虹表：攻击者预先算好的「常见口令 → 哈希」对照表，是按无 salt 或固定 salt 算的。每个用户 salt 不同，这张表就作废了；
② 防止批量破解：没有 salt 时，两个相同密码的用户哈希值完全一样，攻击者一眼就能看出「这俩人用了同一个密码」，还能一次破解多人。加了 salt 后，同样的密码也会产生完全不同的值。
Salt 不需要保密，和哈希结果存一起就行。关键是随机且唯一（至少 16 字节）。
迭代次数是不是越高越好？
原则是在用户能接受的等待时间内取最大值，但不是无限高：
· 登录时每次都要算一次，超过 1 秒用户就会明显感觉卡；
· 服务端还要乘以并发量，1000 人同时登录 × 0.6 秒 = 需要不少算力；
· 迭代到 500 万次，还不如换算法——Argon2id / scrypt 在相同耗时下防护更强。
实际建议：PBKDF2-SHA256 用 60 万次（OWASP 下限），并预留参数升级机制（把迭代次数存进数据库，以后可以调）。
Web Crypto 里有 Argon2 / bcrypt 吗？
没有。Web Crypto 规范目前只提供 PBKDF2 和 HKDF 两种派生函数，没有 Argon2、bcrypt、scrypt。
原因之一是这些算法依赖大量内存（抗 ASIC 的关键），在浏览器这种不可控环境里容易引发资源问题。
所以要：
· 浏览器端做口令派生 → 只能用 PBKDF2（或引入 WASM 版 Argon2 库）；
· 服务端存密码 → 优先用 Argon2id，其次是 bcrypt / scrypt，PBKDF2 作为兼容兜底。
输出长度选多少？
看用途：
· 128 位（16 字节）：够用于派生对称密钥（AES-128）；
· 256 位（32 字节）：最常用，可直接当 AES-256 密钥，也够做密码哈希；
· 512 位：需要从一个口令派生多把密钥时才用。
注意：PBKDF2 的输出长度不会显著提升抗破解能力（安全性主要来自迭代次数），只影响能拿多少字节的密钥材料。另外，输出超过哈希本身的长度（如 SHA-256 要 512 位）时，PBKDF2 会分多轮计算，耗时也会相应增加。

💬 留言板 0

全部留言需审核通过后展示
💬

还没有留言，来抢沙发吧！

✍️ 说点什么
0 / 500
图形验证码

🔗 相关工具推荐

🔐 AES 加密解密派生出的密钥拿去加密 → ✍️ HMAC 签名接口验签用这个 → 🗝️ 密钥对生成非对称密钥场景 → 🎲 随机密码生成先有个强口令 →