bcrypt 哈希计算

免费在线 bcrypt 哈希计算 工具。100% 本地计算，数据不离开您的设备，隐私安全有保障。

General
Password Hashing / KDF
Specialized
Deprecated
输出

结果将显示在这里...

输入 → 计算哈希

使用指南

关于 bcrypt

bcrypt 是由 Niels Provos 和 David Mazières 于 1999 年设计的密码哈希函数，基于 Blowfish 分组密码实现。它的核心设计目标是故意降低运算速度，使暴力破解在计算上不可行。bcrypt 是目前部署最广泛的密码哈希算法之一，Rails、Django、Laravel、Node.js（bcryptjs）等主流框架均原生支持。每个 bcrypt 哈希值内嵌了随机盐值和成本因子，因此哈希字符串本身包含验证所需的全部信息。

经过时间验证的标准：bcrypt 已在生产环境中使用超过 25 年，至今仍是可靠的密码存储方案。 OWASP 推荐最低成本因子为 10，2023 年基准推荐 cost=12。对于新项目，建议优先选择 Argon2id；bcrypt 对现有系统仍然完全可靠。

使用步骤

本工具支持两种操作：哈希密码（加密模式）和验证密码（解密模式）：

•
1. 哈希模式（加密）选择「加密」模式，在输入框填入密码，点击「计算哈希」
•
2. 获取哈希值输出为 60 个字符的 bcrypt 字符串，如 $2b$12$...，复制后存入数据库
•
3. 验证模式（解密）选择「解密」模式，在输入框以 password|$2b$12$... 格式（竖线分隔）填入密码和哈希，点击「解密」
•
4. 查看结果密码正确时显示「✓ Password matches」，不匹配时显示错误提示
隐私保护：所有 bcrypt 计算在浏览器本地完成，数据不会上传服务器，完全离线处理。

算法特点

bcrypt 具备以下使其适合密码存储的特性：

•
故意慢速Blowfish 密钥调度算法计算开销较大，使每次哈希运算耗时较长，大幅提高暴力破解成本
•
内置盐值每个哈希包含唯一的 128 位随机盐值，防止彩虹表攻击和相同密码产生相同哈希的问题
•
可调成本因子成本因子（4–31）控制运算量，每增加 1 级计算时间翻倍，可随硬件升级持续提高安全性
•
抗 GPU 攻击Blowfish 密钥调度的内存访问模式限制了 GPU 并行能力，比 MD5、SHA-256 等简单哈希函数更难被 GPU 加速破解
•
自包含哈希60 字符输出（$2b$12$[22 字符盐值][31 字符哈希]）包含验证所需的全部参数，无需额外存储元数据
与 Argon2 相比的局限性：bcrypt 在计算过程中仅使用约 4 KB 内存，对 ASIC 和定制硬件攻击的抵抗力明显弱于 Argon2（后者需要数十 MB 内存）。对于新项目，推荐优先选择 Argon2id；维护现有系统时继续使用 bcrypt 仍是合理的选择。

成本因子选择指南

选择合适的成本因子需要在安全性和服务器性能之间取得平衡：

•
cost=10OWASP 最低要求（2023）。现代服务器约 100 ms。适用于低流量站点或资源受限环境
•
cost=12OWASP 2023 基准推荐。约 400 ms。适合大多数 Web 应用，安全性与性能均衡
•
cost=14约 1.5 秒。适用于金融、医疗等高安全需求场景。可能需要异步处理以避免阻塞 UI
•
cost=31（最大值）理论最大值，计算耗时数小时。仅用于演示或离线归档，切勿在生产环境使用
调优建议：在生产服务器上进行基准测试，选择使单次哈希耗时控制在 200–500 ms 的最高成本因子。随着硬件升级，每隔 2–3 年增加成本因子。新哈希使用新成本因子，旧哈希仍可正常验证，因为成本因子已存储在哈希字符串中。

常见问题

Q: bcrypt 的哈希字符串格式是什么？

A: bcrypt 哈希始终为 60 个字符，格式如下：$2b$12$LQv3c1yqBWVHxkd0LHAkCOYz6TtxMQJqhN8/lewdBdXyXu2zXpOme。
各部分含义：
$2b$：bcrypt 版本标识符（2b 为当前标准；旧哈希可能显示 2a 或 2y）。
12$：成本因子（此处为 12）。
后 22 个字符：Base64 编码的 128 位随机盐值。
最后 31 个字符：Base64 编码的 184 位派生哈希值。
关键特性：所有参数均嵌入字符串中，验证时无需额外存储任何信息。

Q: bcrypt 和 Argon2 有什么区别？

A: bcrypt（1999）：计算困难，约 4 KB 内存，中等抗 GPU 能力，各语言和框架普遍支持。 Argon2（2015）：内存困难（可配置，默认 64 MB），抗 ASIC/GPU 能力更强，OWASP 和 NIST 首选算法。何时使用 bcrypt：维护已使用 bcrypt 的现有系统，或 Argon2 暂不可用的环境。何时使用 Argon2：所有新项目 —— 在同等甚至更好性能下提供更强安全性。迁移方案：bcrypt 和 Argon2 哈希可通过前缀（$2b$ 与 $argon2id$）自动区分，支持渐进式并行迁移。

Q: 为什么 bcrypt 不能用于文件或大数据哈希？

A: bcrypt 存在 72 字节输入限制。超过第 72 个字节的内容会被静默截断 —— 两个前 72 字节相同的密码将产生相同的哈希，这是安全漏洞。 对于文件完整性或通用数据哈希，应使用 SHA-256 或 SHA-512。bcrypt 专为短小的人工输入密码设计。如需哈希较长的密钥（如 OAuth Token），可先用 SHA-256 预哈希再传入 bcrypt，但此类场景建议直接使用 Argon2。

Q: 数据库泄露后 bcrypt 还安全吗？

A: 是的。bcrypt 是单向哈希，不存在任何算法可以将其还原为原始密码。获取数据库的攻击者必须逐一猜测密码并运行 bcrypt（每次运算耗时较长）。在 cost=12 下，单核 CPU 每秒只能尝试约 2–5 次哈希，对于强密码而言穷举攻击实际上不可行。但 bcrypt 无法保护弱密码或常见密码（如「password123」）—— 务必在注册时强制实施最低密码强度策略，并考虑接入泄露密码筛查服务（如 Have I Been Pwned API）。

Q: 生产环境应该使用哪个成本因子？

A: OWASP 2023 推荐：cost=12 作为基准。具体取值取决于服务器硬件：基准测试方法：在生产服务器上运行 bcrypt，选择使单次哈希耗时不超过 500 ms 的最高成本因子，在攻击者猜测速度和用户体验之间取得最优平衡。最低下限：生产用户密码的成本因子不得低于 10。定期复查：随着硬件升级，每隔 2–3 年适当提高成本因子，并在用户下次登录时重新哈希。注意：成本因子存储在哈希字符串中，不同成本因子的旧哈希和新哈希可以共存，均能正确验证。

Q: bcrypt 可以用于 API 密钥或令牌存储吗？

A: 可以，但需注意适用场景。bcrypt 适合哈希长度不超过 72 字节且验证频率较低的 API 密钥和令牌。由于 API 密钥通常是高熵随机字符串，数据库泄露后被破解的风险低于用户密码 —— SHA-256 + 盐值方案在此场景下往往速度更快且已足够安全。避免在高频验证场景（如每次 API 请求）中使用 bcrypt —— 正确做法是在令牌签发时哈希一次，存储哈希值，后续使用常数时间比较。Session Token 和 JWT 应使用 HMAC-SHA256 签名而非 bcrypt 哈希。

使用场景

推荐：用户密码存储

这是 bcrypt 的核心应用场景，也是其最擅长的领域。用户注册或修改密码时，使用 bcrypt（cost ≥ 12）哈希密码并将 60 字符字符串存入数据库。登录时，提取存储的哈希字符串，对用户输入的密码执行 bcrypt 验证并比对结果。由于盐值和成本因子均嵌入哈希字符串，无需额外的数据库字段。Rails（has_secure_password）、Django（默认密码哈希器）、Laravel（Hash Facade）和 Node.js（bcryptjs / bcrypt 包）均原生支持 bcrypt。

推荐配置：
  • ✅ bcrypt（cost ≥ 12，广泛支持 —— 现有系统推荐）
  • ✅ Argon2id（新项目首选 —— 抗 ASIC 能力更强）
  • PBKDF2-SHA256（≥ 600k 迭代，适用于 FIPS 合规环境）
  • ❌ 不要使用 SHA-256、MD5 等通用哈希函数存储密码
推荐：遗留系统兼容

许多生产系统已积累了数年乃至数十年的 bcrypt 哈希数据。全量替换算法意味着所有现有哈希失效，并强制所有用户重置密码 —— 这既影响用户体验，也存在运营风险。对于此类系统，继续使用 bcrypt 并随硬件升级提高成本因子是合理选择。新用户注册或现有用户修改密码时，可透明地切换至 Argon2id，同时以 $2b$ 前缀识别的旧 bcrypt 哈希继续正常验证。

推荐配置：
  • ✅ 保留 bcrypt 用于现有哈希 —— 无需强制迁移
  • ✅ 渐进式引入 Argon2id 用于新注册和密码修改
  • ✅ 通过哈希前缀（$2b$ vs $argon2id$）自动路由验证逻辑
  • 💡 记录每个用户使用的算法类型，跟踪迁移进度
可接受：API 密钥哈希

bcrypt 可对 API 密钥进行哈希后再存入数据库，防止数据库泄露时暴露可用凭据。由于 API 密钥是随机高熵字符串，暴力破解 bcrypt 哈希实际上不可行，即便使用较低成本因子（cost=10）也如此。但 bcrypt 仅适用于验证频率较低的场景（如每次会话验证一次）。对于大规模每请求验证，应改用快速的 HMAC-SHA256 方案，或存储密钥的 SHA-256 哈希（高熵密钥使彩虹表无效）。切勿明文存储 API 密钥。

推荐配置：
  • ✅ bcrypt（cost=10–12，适合低频验证）
  • ✅ SHA-256 + 盐值（更快，适合高熵密钥）
  • ✅ HMAC-SHA256（用于每请求令牌签名）
  • 💡 使用哈希前缀（前 8 位）作为数据库索引加速查询
不推荐：文件加密或数据加密

bcrypt 是单向哈希函数，而非加密算法 —— 不存在解密步骤，无法加密文件或任意数据。此外，bcrypt 的 72 字节输入限制使其不适合对文件内容或长字符串进行哈希。文件加密应使用对称密码（如 AES-256-GCM）。若需要从密码派生加密密钥，应使用密钥派生函数： Argon2id 或 scrypt 比 bcrypt 更适合此用途。

推荐配置：
  • ❌ 不要用 bcrypt 进行文件加密（单向不可逆）
  • ❌ 不要用 bcrypt 哈希超过 72 字节的数据
  • ✅ 使用 AES-256-GCM 进行对称文件加密
  • ✅ 使用 Argon2id 或 scrypt 进行基于密码的密钥派生
不推荐：通用数据哈希

bcrypt 对于通用数据完整性校验、内容指纹、去重或需要快速处理大量数据的场景来说过于缓慢。这些需求应使用快速密码学哈希： SHA-256 或 SHA-512 用于完整性验证，BLAKE2/SHA-3 用于高性能场景。bcrypt 的故意慢速在密码存储中是优势，在其他场景中则是负担。

推荐配置：
  • ❌ 不要用 bcrypt 做数据完整性校验或内容哈希
  • ✅ SHA-256（通用完整性哈希）
  • ✅ BLAKE2b（高速密码学哈希）
  • ✅ SHA-3 / SHA-512（更高安全裕量）
不推荐：高频认证场景

bcrypt 在 cost=12 下每次耗时约 200–500 ms。若在每次 API 请求或 WebSocket 消息中运行 bcrypt，服务器将不堪重负。高频认证应依赖无状态令牌（使用 HMAC-SHA256 或 EdDSA 签名的 JWT）或带快速令牌查询的服务端会话。bcrypt 只在登录时调用一次—— 密码验证成功后签发短期令牌，后续请求凭令牌进行快速、无 bcrypt 的认证。

推荐配置：
  • ❌ 不要在每次 API 请求中运行 bcrypt
  • ✅ JWT + HMAC-SHA256（无状态、高性能每请求认证）
  • ✅ Session + Cookie（传统服务端会话管理）
  • ✅ OAuth 2.0 / OpenID Connect（联合身份，基于令牌）

最佳实践总结

  • 现有系统使用 bcrypt（cost ≥ 12）存储用户密码。新项目优先选择 Argon2id —— 抗 ASIC 能力更强，性能相当甚至更好。
  • 不要将 bcrypt 用于通用数据哈希、文件加密或超过 72 字节的数据。它专为短小的人工输入密码设计。
  • 在生产服务器上进行基准测试，目标单次哈希耗时 200–500 ms。每隔 2–3 年随硬件升级提高成本因子。
  • 高频认证场景中，bcrypt 仅在登录时调用一次，之后签发 JWT 或 Session Token 用于后续请求认证。
  • 从 bcrypt 迁移至 Argon2id 采用渐进式方案：保留旧哈希的 bcrypt 验证，新注册和密码修改使用 Argon2id，通过哈希前缀自动识别算法。

讨论与反馈

0 条评论
我