bcrypt 生成器

bcrypt 仍然是存储密码的安全选择之一。它有意保持较慢,会生成自己的 salt,并通过可调 cost 参数随着硬件进步而扩展成本。这个生成器会从 plaintext password 生成符合标准的 bcrypt hash,方便你 seed 测试用户、在系统之间迁移账户,或与 users.password 字段中已有的 hash 值比对。

如何用 bcrypt 哈希密码

  1. 1

    输入 plaintext password

    最多 72 bytes — bcrypt 会静默截断超出的部分。

  2. 2

    选择 cost factor

    10 是当前默认值;12 常用于新系统;14 属于偏保守的高安全设置。每增加 1,哈希时间大约翻倍。

  3. 3

    生成随机 salt

    从 cryptographic RNG 中取 16 bytes salt,并嵌入最终 hash 字符串。

  4. 4

    复制 hash

    输出是类似 `$2b$12$...` 的 self-describing 字符串,包含 version、cost、salt 和 digest。

bcrypt hash 的结构

$2b$12$mE2n5YqWjKqT9tXg.OQPoeeHZJ9hdSvOt5wFdRRQwl6yE1vWWY3z6
  |   |  |                      |
  |   |  salt (22 Base64 chars)  digest (31 Base64 chars)
  |   cost (2 digits, 4-31)
  version (2a, 2b, 2y — all bcrypt)

整个字符串为 60 个字符。类型为 VARCHAR(60)CHAR(60) 的字段是标准 schema。

Cost factor 建议

成本因子 每次哈希约耗时(2024 年 CPU) 应用场景
10 ~80 ms 旧版默认值,仍可接受
12 ~300 ms 当前推荐的基准
13 ~600 ms 更高安全性的应用
14 ~1.2 s 偏执级;登录延迟明显

每增加 1,work factor 翻倍。如果登录延迟必须低于 500 ms,建议保持在 10-12。

Version byte:2a vs 2b vs 2y

  • $2a$ — 1999 年原始规范。多数库会输出 2a hashes。
  • $2b$ — 2014 年修订版,修复 crypt_blowfish 中的截断 bug。新 hash 首选。
  • $2y$ — PHP-specific tag,功能上等同于 $2b$

三者可以互相验证;区别只在 hash 字符串中的 tag。

bcrypt 能防什么

  • Rainbow tables — 每个 hash 唯一的 salt 会击败预计算查找。
  • GPU/ASIC cracking — Blowfish key schedule 受内存限制,对 GPU 不友好。它不如 Argon2 那样针对 GPU 强硬,但暴力破解仍然很慢。
  • Database leaks — 不通过暴力破解,无法从 hash 恢复 plaintext。

bcrypt 不能防的内容:弱密码(使用最小长度,并检查泄露密码列表)、credential stuffing(使用第二因素)、phishing。

72-byte 限制

bcrypt 只使用密码的前 72 bytes。更长输入会被静默截断,这也是许多库现在建议先用 SHA-256 预哈希密码,再送入 bcrypt 的原因。现代替代方案(Argon2、scrypt)没有这个限制。

常见问题

用于密码存储仍然安全,前提是 cost ≥ 12。OWASP 仍将它列为可接受算法。Argon2id 是新系统的首选,但迁移 legacy bcrypt hashes 通常不是高优先级事项。

因为每个 hash 都会随机生成 salt。验证时会从存储的 hash 中取出 salt,用它重新哈希提交的密码再比较。

多数库不会暴露这个能力,而且理由充分 — 可预测的 salts 会破坏它的意义。使用库生成的 salt 才是安全路径。

会 — work factor 是对称的。验证 cost-14 hash 比验证 cost-10 慢 16 倍。请根据登录吞吐量调优。

相关工具