密码哈希工具
在线生成与验证密码哈希：支持 bcrypt 与 PBKDF2 两种主流算法， 盐值由浏览器 CSPRNG 自动生成并嵌入哈希串。bcrypt 通过 cost 因子调节计算成本（每加 1 翻倍）， PBKDF2 通过迭代数与哈希函数（SHA-256 / SHA-512）调节。基于 bcryptjs 与原生 Web Crypto API， 全本地处理，密码不离开浏览器。
常见问题
什么是密码哈希？为什么不能直接存密码明文？
密码哈希是将用户密码通过单向函数转换为不可逆的固定长度字符串的过程。 哈希后的字符串无法逆向还原出原密码，即使数据库泄露，攻击者也无法直接获得密码。 直接存密码明文是严重的安全隐患——一旦数据库泄露，所有用户密码暴露无遗。
正确的存储方式是：密码 + 随机盐 → 哈希算法 → 哈希串，数据库只存哈希串。 验证时将用户输入的密码以相同流程计算哈希，与数据库存储的哈希比对即可。
bcrypt 和 PBKDF2 有什么区别？哪个更安全？
两者都是业界主流的密码哈希算法，安全性都依赖正确的参数配置：
- bcrypt：1999 年发布，基于 Blowfish 加密算法改造。
通过 cost 因子调节计算成本（cost=12 约 200ms），算法本身设计抗 GPU/ASIC 加速。
哈希格式
$2a$cost$22位盐$31位哈希自包含盐与参数，便于迁移。 - PBKDF2：2000 年标准化（RFC 2898），基于 HMAC 重复迭代。 通过迭代数与哈希函数（SHA-256/SHA-512）调节成本，被各大平台广泛采用（如苹果、微软）。 迭代数越高越安全，但相对而言对 GPU 加速攻击的抵抗力弱于 bcrypt 与 scrypt/Argon2。
建议：新项目优先选 bcrypt（cost ≥ 12）；若必须使用 PBKDF2， OWASP 2023 建议 SHA-256 迭代数 ≥ 600,000 或 SHA-512 ≥ 210,000。 更前沿的选项是 Argon2id（Password Hashing Competition 2015 冠军）， 但浏览器原生不支持，需引入 WASM 库。
bcrypt 的 cost 因子怎么选？越大越好吗？
cost 因子是 bcrypt 的核心安全参数，每加 1 计算耗时翻倍。参考基准（现代 CPU 单核）：
- cost=10：约 50ms，适合开发测试
- cost=12：约 200ms，生产环境推荐下限
- cost=14：约 1-3s，对登录体验有感知延迟
- cost=15+：不建议在浏览器执行，会阻塞 UI 数秒
不是越大越好：cost 越高，登录响应越慢，用户体验越差。 NIST 与 OWASP 建议将 cost 设置为「用户可接受的最大延迟」对应的值—— 通常服务器端选择 cost=12-14（约 200ms-3s），浏览器端演示建议 cost ≤ 12。 随着硬件进步，应每 2 年评估并提升 cost。
为什么每次生成的哈希都不一样？
因为每次哈希都会生成新的随机盐（salt）并嵌入哈希串中。 盐是 16 字节的密码学安全随机数，作用是：
- 抵御彩虹表攻击：相同密码每次哈希得到不同结果，预计算的彩虹表失效
- 防止相同密码被识别：两个用户用相同密码，数据库中存的哈希也不同
- 增加暴力破解成本：攻击者必须针对每个哈希单独计算，无法批量加速
验证时哈希函数会从存储的哈希串中提取盐与 cost，自动用相同参数重新计算并比对。 这就是为什么盐可以公开（嵌入在哈希串里）——它本身不是密钥，只是让哈希结果唯一。
本工具的 PBKDF2 哈希格式是什么样的？
本工具输出标准化的 PBKDF2 哈希字符串，格式为：
pbkdf2$<iterations>$<hashName>$<saltBase64>$<hashBase64>例如：
pbkdf2$100000$SHA-256$wHZS9xnmaTCrhjvBxQ9T3w==$lUfRw1i1Lv0lLBJCNIYq1w==各字段含义：
iterations：迭代次数，如 100000hashName：底层哈希函数，SHA-256 或 SHA-512saltBase64：16 字节盐的 Base64 编码（24 字符含填充）hashBase64：派生哈希的 Base64 编码（SHA-256 输出 32 字节 = 44 字符；SHA-512 输出 64 字节 = 88 字符）
验证时工具会自动解析该格式并使用相同参数重新派生，常数时间比对避免时序侧信道。 注意：本格式与 Django、Passlib 等库的格式兼容但非完全一致，迁移时请确认目标库的格式规范。
bcrypt 的 $2a$、$2b$、$2y$ 前缀有什么区别？
这是 bcrypt 哈希的版本标识，差异主要在历史实现细节：
$2a$：原始规范（1999），最广泛支持，本工具默认使用$2b$：OpenBSD 2014 修订版，修复了早期实现中处理超长密码的边界问题$2y$：PHPcrypt()函数使用的标识，与 $2b$ 行为等价$2x$：极旧版本，已弃用，存在已知漏洞
建议：新项目用 $2b$ 或 $2a$，本工具为最大兼容性默认 $2a$。
验证时 bcryptjs 同时支持三种前缀，无需手动区分。
在浏览器里做密码哈希安全吗？性能怎么样？
安全。本工具的密码与哈希全程在浏览器本地处理，不发送到任何服务器， 不记录、不上传。即使断网也能使用。
性能方面：
- bcrypt：bcryptjs 是纯 JavaScript 实现，cost=12 约 200-400ms，cost=14 约 1-3s。计算时会短暂阻塞主线程（UI 显示「计算中」），可接受
- PBKDF2：使用 Web Crypto API 原生实现，由浏览器底层 C++ 执行，100,000 次迭代约 50ms（SHA-256），完全异步不阻塞
生产环境推荐在服务端计算哈希（Node.js 用 bcrypt 或 argon2 库，性能比浏览器快 5-10 倍）， 本工具用于学习、调试、对比算法、教育演示，不应用于生产密钥管理。