Bcrypt 生成器 - 在线创建密码哈希
Bcrypt Generator
Hashing runs locally in your browser. Your password is never uploaded or stored.
功能介绍
密码哈希是一种单向函数，把口令转换成固定长度的字符串，使得原口令无法从哈希中还原，但可以把同一个口令再次哈希后与原值比对以完成校验。bcrypt 就是本工具实现的具体算法，由 Niels Provos 与 David Mazieres 设计，1999 年作为 OpenBSD 口令哈希方案发布，属于自适应（刻意高开销）密钥派生函数一族，构建在 Blowfish 分组密码之上。把它和普通哈希区分开来的核心是速度：SHA-256 之所以快，是因为它被设计来在每秒钟计算几十亿次，而这恰恰是密码存储最不需要的特性，攻击者拿到泄露的哈希表就能获得海量免费猜测。bcrypt 反其道而行之，刻意让单次计算变慢，并且把这个开销做成可调的参数，于是你可以随着硬件进步不断调高强度，而不用改变存储格式。在结构上，bcrypt 会生成一个随机的 128 位盐值，把它与口令混合，然后以可调的次数执行昂贵的 EksBlowfish 密钥调度，该次数即计算强度的以 2 为底的对数，这也是为什么强度每加一耗时大约翻两番。由于盐值被嵌入输出中，同一口令两次生成的 bcrypt 哈希是不同的字符串，这让攻击者无法识别出哪些账户使用了相同口令，也直接击穿了彩虹表这类预计算攻击。输出采用 modular crypt 格式，以版本前缀开头，随后是计算强度、盐值的 22 位 base64 编码、哈希结果的 31 位编码，各段之间用美元符号分隔，完整长度固定为 60 个字符。实践中有两点后果很重要。第一，bcrypt 会静默忽略超过 72 字节的输入，因此更长的口令应先用 SHA-256 做预哈希并做 base64 编码再交给 bcrypt，否则两个前缀相同的长口令会变得可以互相替换。第二，算法在设计上是单向的：验证需要明文口令，这正是 bcrypt 绝不能用于任何需要读回数据的场景的原因，比如记住银行卡号或做可逆的口令找回，那些场景必须用真正的加密和受管理的密钥。
使用方法
- 在浏览器中打开 Bcrypt 生成器。哈希计算在本地完成，你的口令不会被上传到任何地方。
- 在输入框中填入要哈希的口令。建议使用较长的口令短语，因为长度带来的抗破解能力远高于符号替换。
- 从 4 到 15 之间选择计算强度，不确定就保持推荐默认值。强度越高耗时越长，也越难被攻击。
- 查看强度旁显示的耗时，确认它落在你的目标区间内，生产硬件上通常为 150 到 400 毫秒。
- 点击生成得到哈希，然后复制完整字符串（包含版本前缀、强度和盐值）存入你的密码库。
- 使用验证区域对已有哈希校验口令，适合测试集成或迁移已存储的凭据时使用。
- 务必存储完整哈希字符串而不是仅保存后半段，因为 bcrypt 在校验时必须同时存在版本、强度和盐值前缀。
计算示例
输入: 口令：correct-horse-battery-staple，计算强度 10
过程:
生成 128 位随机盐，执行 2^10 轮 EksBlowfish，再做 base64 编码结果: 以 $2b$10$ 开头的 60 字符哈希 — 校验需要同样的明文
输入: 同一口令在相同强度下哈希两次
过程:
每次调用都生成全新的随机盐值结果: 完全不同的两个哈希字符串，对应完全相同的输入
输入: 典型服务器硬件上的强度对比
过程:
强度 10 执行 2^10 轮，强度 12 执行 2^12 轮，强度 14 执行 2^14 轮结果: 每升一级工作量约翻两番，强度 14 的耗时约为强度 10 的 16 倍
相关搜索
相关搜索：bcrypt生成器, bcrypt哈希, 密码哈希生成, bcrypt计算强度, bcrypt盐值, 哈希密码。
bcrypt生成器bcrypt哈希密码哈希生成bcrypt计算强度bcrypt盐值哈希密码验证bcrypt哈希bcrypt与sha256bcrypt轮数生成加盐哈希安全的密码存储密码哈希工具在线bcryptargon2替代bcrypt工作因子node bcryptpython bcrypt单向哈希bcrypt强度12离线密码哈希
常见问题
bcrypt 的计算强度应该设成多少？
对多数生产系统来说，计算强度 12 是一个稳妥的默认值，在典型服务器硬件上每次哈希约 250 到 400 毫秒，而强度 10 在今天面对配备现代 GPU 的攻击者往往已经不够快。真正重要的是选择一个让你自己的登录流程感觉平常的数值，因为哈希发生在身份验证过程中，任何明显偏慢都会造成可用性问题，进而把人推向重新认证之类的旁路。如果你的服务器性能特别强，可以先在强度 12 下实测，再逐步提高到 13 或 14，直到单次哈希耗时几百毫秒。绝不要直接照搬别的项目的数值，因为这个数字只有相对于执行它的硬件才有意义；同时要把已存储的强度视为需要随硬件进步重新测量并上调的量。
为什么同一个口令两次生成的哈希不一样？
因为 bcrypt 为每一次哈希都生成全新的随机 128 位盐值。这个盐值本身不是秘密，它只是被记录在输出中以便校验时复现最初的运算，但它的随机性确保了相同口令在不同账户上产生完全无关的哈希字符串。这击穿了一大类预计算攻击，包括彩虹表——攻击者预先把常见口令全部哈希一遍然后查表匹配。它还避免了一种更隐蔽的泄露：如果攻击者拿到你的用户表，原本可以直接通过比较哈希字符串看出哪些账户共用口令。实际含义是，你无法通过比较已存储的 bcrypt 哈希来判断口令是否重复，必须逐个用候选口令去验证，这也正是检测口令复用必须主动尝试验证的原因。
存密码用 bcrypt 还是 SHA-256 更好？
请用 bcrypt，原因在于计算强度而非什么高深的数学。单轮 SHA-256 被设计得极快，而这恰恰是密码存储最不需要的特性，因为 GPU 每秒能计算数十亿次，攻击者拿到泄露的哈希表后就能获得海量免费猜测。bcrypt 刻意设计得慢，且单次开销可调，因此你可以在硬件进步时不断调高强度而不必改变存储格式。Argon2id 目前在可用时更受推荐，是新建系统的更优选择，而 bcrypt 依然完全可接受且支持面广得多。无论你选哪种算法，绝不要用朴素的 SHA-256 存储口令，也绝不要使用任何无盐哈希。
bcrypt 哈希能反解回原始口令吗？
不能，而这正是选择密码哈希而非加密的全部意义。bcrypt 是单向函数，不存在任何密钥、参数或付费工具能把哈希还原成口令。从 bcrypt 哈希恢复口令的唯一现实途径是猜测候选口令，用相同的强度和盐值分别哈希后比对，而这恰恰是 bcrypt 设计上要让其变慢的攻击。这也解释了一个让人意外的约束：凡是之后还需要读回原值的东西都不能用 bcrypt，比如存储的银行卡号、客户加密密钥或可逆的口令找回，因为系统将无法取回原值。那些场景需要真正的加密和受管理的密钥，而不是单向哈希。
如果存哈希时漏掉了计算强度和盐值会怎样？
那么哈希永远无法通过校验，账户也无法恢复，因为 bcrypt 需要这四段信息才能复现运算。完整的 bcrypt 哈希由版本前缀、计算强度、盐值和结果哈希组成，用美元符号连接，总长度固定为 60 个字符。bcryptjs 和 Python 的 bcrypt 包都会在一次 generate 调用中返回这个完整字符串，因此你的数据库列应保存整个值而不是裁剪后的片段。只存最后一段、或者只存盐值之后的部分，会悄无声息地让所有用户无法登录，而且无论怎么排查口令本身都找不到原因。对任何声称存放 bcrypt 哈希的字段做一次 60 字符的长度检查，是个很有用的基本校验。
bcrypt 对口令长度有上限吗？
bcrypt 只考虑口令的前 72 个字节，之后的内容会被忽略，这是它 Blowfish 密钥调度的历史遗留特征，而非有意设置的安全上限。实际后果是两个长度超过 72 字节且前缀相同的口令可以互相通过验证，因此一个前 72 字节与他人相同的 100 字符口令短语会被当作同一个口令。对于长口令短语来说这是真实风险，而长口令恰恰是你应该鼓励用户使用的，像完整句子这样的内容很容易超过这个限制。标准做法是先用 SHA-256 加 base64 对口令做预哈希，再把定长结果交给 bcrypt。如果你的语言库默认已处理，请优先使用该实现；否则在依赖超长口令短语之前先确认其行为。