Bcrypt 生成器 — 用 bcrypt 加密和验证密码
按你选择的成本因子用 bcrypt 哈希密码，校验密码与 bcrypt 哈希是否匹配，并了解哈希各部分的含义。
生成 bcrypt 哈希
用哈希验证密码
| 版本 | $2b$ | 2b — OpenBSD 于 2014 年针对超过 255 字节密码的修复版本。目前 bcrypt（C/Python/Node）的默认版本。 |
|---|---|---|
| 成本因子 | 10 | 2^10 = 1,024 轮密钥扩展 |
| 盐值 | O.0JDwgDTALNNPsTWXP1YO | 22 个字符 = 128 位随机数，bcrypt Base64 编码 |
| 哈希 | 2o9FuEFCZZMBsOKg910t7.RrUqVQsmW | 31 个字符 = 192 位输出中的 184 位 |
密码在你的浏览器中通过 bcryptjs 进行哈希和验证，不会发送、存储或记录任何内容。尽管如此，也请避免将正在使用的生产环境密码粘贴到任何网页中。 浏览全部免费工具.
发现问题，或者觉得哪里可以更好？每条消息我们都会阅读，并尽快修复。
这款 bcrypt 生成器可以用 4 到 15 的成本因子对密码进行 bcrypt 哈希，验证密码与现有 bcrypt 哈希是否匹配，并把哈希拆解为版本、成本、盐值和摘要。它适合用来创建测试用户、在数据迁移时核对数据库中的哈希是否对应某个已知密码，或者弄明白 $2b$12$ 到底是什么意思。哈希计算在浏览器中通过 bcryptjs 完成，这是一个 JavaScript 实现，与 Node.js、PHP、Python、Ruby 和 Go 使用的 bcrypt 库相互兼容。如果要创建多个测试账号，批量模式可以一次哈希最多 50 个密码。
Bcrypt 是故意设计得很慢的，成本每增加 1，耗时就翻一倍。工具在计算时会显示进度，并估算其他成本因子在你的设备上需要多长时间，方便你在为服务器选定成本前先看清其中的取舍。有一点提醒适用于所有在线工具：不要把正在使用的生产环境密码粘贴到你无法掌控的网页上。请只用它处理测试数据和理解哈希。
使用方法
- 输入密码并选择成本因子；登录系统通常使用 10 到 12。
- 点击“生成哈希”。运行时会显示进度条；成本为 14 或 15 时可能需要好几秒。
- 复制这个 60 个字符的哈希。由于盐值是随机的，再次生成会得到不同的哈希；两者都能通过验证。
- 要校验哈希，把它和待验证的密码一起粘贴到验证区域，然后点击“验证”。
- 查看哈希结构表，了解该哈希使用的版本和成本。
常见问题
可以一次 bcrypt 多个密码吗？
可以。切换到“密码列表（批量）”，每行粘贴一个密码，最多 50 个（空格也算字符；空行会被跳过），然后点击“哈希”。它们会按你选择的成本依次哈希，每个都有自己的随机盐值，处理期间页面仍可正常操作。你可以按列表顺序复制哈希，也可以下载 CSV（可选择是否包含明文密码）。之所以设上限，是因为 bcrypt 本来就很慢：成本为 12 时，50 个哈希就已经要花上一段时间。
bcrypt 应该用多大的成本因子？
选择能让生产服务器上单次哈希的延迟仍可接受的最高成本，通常为 100 毫秒到 1 秒。在当前的服务器硬件上，这一般是 10 到 12。OWASP 的《密码存储速查表》规定最低工作因子为 10。请在真实服务器上测量，而不是在笔记本上；还要记住，成本越高，登录接口也越容易被大量请求压垮。
为什么同一个密码每次生成的 bcrypt 哈希都不一样？
每个哈希都包含一个新的 128 位随机盐值，就存放在哈希本身里（成本后面的 22 个字符）。这是有意为之：两个使用相同密码的用户会得到不同的哈希，预先计算的彩虹表也就毫无用处。验证密码时，bcrypt 从存储的哈希中读出盐值和成本，用它们重新哈希待验证的密码，再进行比较。
bcrypt 哈希可以解密吗？
不可以。Bcrypt 是单向哈希，而不是加密。要从 bcrypt 哈希还原密码，唯一的办法是猜测候选密码并逐个哈希，而成本因子让每次猜测都代价高昂。这正是它的目的：弱密码仍可能被猜中，但每次尝试都要耗费实打实的 CPU 时间，而不是几纳秒。
$2a$、$2b$ 和 $2y$ 有什么区别？
它们标记的是该算法实现的不同修订版本。$2a$ 是长期使用的版本；$2b$ 由 OpenBSD 于 2014 年引入，修复了对超过 255 字节密码的处理；$2y$ 是 PHP 在 2011 年修复一个符号扩展 bug 后，为其生成的哈希使用的标记。对于当前库生成的哈希，三者的验证方式相同，大多数库也都接受这三种。
bcrypt 的密码有最大长度吗？
有。Bcrypt 只使用密码的前 72 个字节，其余部分会被忽略，而且按 UTF-8 字节计算，所以由带重音字母或表情符号组成的密码，用更少的字符就会达到上限。超过 72 字节时，本工具会发出提醒。如果需要接受更长的密码短语，要么限制其长度，要么改用没有此限制的 Argon2id。
应该用 bcrypt 还是 Argon2？
对于新系统，OWASP 首推 Argon2id，因为它是内存困难型算法，用 GPU 攻击的成本更高。Bcrypt 依然是可靠的选择，而且到处都支持；已经在使用成本 10 及以上 bcrypt 的系统，并不急需更换。最重要的是，你用的是这类慢速、加盐的算法，而不是单纯的 SHA-256 或 MD5。
bcrypt 哈希的结构
像 $2b$12$R9h/cIPz0gi.URNNX3kh2OPST9/PgBkqquzi.Ss7KIUgO2t0jWMUW 这样的 bcrypt 哈希总是 60 个字符，包含了验证所需的全部信息：
• $2b$：算法版本。
• 12$：成本因子。密钥设置要运行 2^12 = 4,096 次。
• R9h/cIPz0gi.URNNX3kh2O：22 个字符，编码 128 位随机盐值。
• PST9/PgBkqquzi.Ss7KIUgO2t0jWMUW：31 个字符，编码 184 位结果。
编码使用的是 bcrypt 自己的 Base64 字母表（./A–Z a–z 0–9），并非标准 Base64 字母表，因此无法用普通的 Base64 解码器解析各部分。
为什么快速哈希不适合存储密码
SHA-256 这类通用哈希的设计目标就是快，一块现代 GPU 每秒可以计算数十亿次。一旦存有 SHA-256 密码哈希的数据库泄露，所有常见密码和大多数短密码都会在几小时内被破解。加盐可以让预先计算的表失效，但不能减慢猜测速度。
Bcrypt 通过让每次哈希都刻意变得昂贵且可调来解决这个问题。成本为 12 时，在典型的服务器核心上一次哈希约需四分之一秒，大约是同一核心上单次 SHA-256 的一百万倍；bcrypt 的内存访问模式也让它在 GPU 上运行效率很低。随着硬件变快，你可以提高成本；现有哈希可以在每个用户下次登录时升级。
哈希只是其中一层防护。还应限制登录尝试频率，按 NIST SP 800-63B 的建议用已泄露密码列表检查新密码，并提供双重身份验证，这样单凭猜中的密码不足以登录。