— — 点击哈希生成 — —关于 Bcrypt 哈希
存储用户口令时，「做一次哈希」远远不够。通用哈希函数（如 SHA-256）被设计得又快又便宜，而这对存储口令恰恰是缺点：攻击者拿到哈希库后可以用显卡每秒尝试数十亿次，一次全库撞库只需很短时间。口令哈希算法的设计目标正相反——故意让每一次尝试变得昂贵，从而把穷举的成本推到不可接受。 这类算法的核心机制有两个。一是加盐：为每个用户生成独立的随机值并混入口令，使得相同的口令得到不同的哈希，同时也让预先计算好的彩虹表失效。二是工作因子：把计算重复若干轮，轮数可以随硬件进步而调高，因此今天设定的成本在数年后仍可通过提高参数来维持。两者结合后，攻击者即使拿到哈希库，也必须为每个用户单独付出高昂代价。 使用要点：每个用户必须有独立的盐，绝不能用一个全局固定值，否则攻击者可以一次性对所有用户复用同一份计算；工作因子应当按当前硬件设定到「单次校验耗时约一百毫秒」这一量级，太低成本无法阻挡穷举，太高则会拖慢登录接口甚至成为拒绝服务的放大器。算法选择上，bcrypt 兼容性最好，scrypt 与 Argon2 在抗显卡与抗专用硬件上更强，新系统建议优先考虑后者。 边界与限制：bcrypt 有一个著名的输入长度限制，超过七十二字节的部分会被截断，因此长口令的第 73 个字节起不起作用，处理超长口令时应先做一次通用哈希再送入，或改用没有该限制的算法。盐与参数必须与哈希一起存储，否则无法校验；升级算法或提高工作因子时，标准做法是在用户下次登录成功时用新参数重新计算并覆盖，称为「渐进式重算」，不要强制所有人同时改口令。此外这类算法校验一次就是几百毫秒，登录接口务必做限流，否则攻击者可用大量无效请求消耗服务器算力。 数据与隐私：本工具用于实验与核对参数，请不要把真实用户的口令或生产环境的哈希值粘贴到任何在线服务中。若确实需要演示，使用明显虚构的示例值；在真实系统里，哈希计算应在服务端完成，浏览器端做口令哈希并不能替代传输层加密。
安全工程上还有几处配套措施不能省：登录接口必须限流并按账号与来源地址分别计数，失败次数达到阈值后延迟响应或暂时锁定，否则再贵的一次哈希计算也挡不住持续请求；校验过程中不要区分「账号不存在」与「口令错误」的响应内容与耗时，否则会泄露账号是否存在；哈希与盐必须随用户记录一起备份，丢失后无法恢复。迁移算法时保留新旧两套校验路径，并在用户下次登录成功时按新参数重算，这样可以在不停机、不强制改密的前提下完成升级。 把这些措施写进上线检查清单，能避免「算法选对了但配套没做」这种最常见的安全缺口。
实现原理
这类算法故意让每次计算变贵。盐为每个用户生成独立随机值并混入口令，使相同口令得到不同哈希并让预先计算好的表失效；工作因子把计算重复若干轮，轮数可随硬件进步调高。二者结合后，攻击者即使拿到哈希库也必须为每个用户单独付出高昂代价。注意输入超过 72 字节会被截断。
口令 hunter2，工作因子 12$2b$12$K3Jd…与 $2b$12$Qp7x…（前缀与轮数相同，盐与摘要不同；校验时两者都能通过）使用方法
- 打开「Bcrypt 哈希」
- 输入待处理的内容并设置参数
- 根据需要调整输出选项
- 点击「生成」按钮，结果实时显示
- 复制或导出结果
使用场景
- 生成测试账号哈希 — 为本地数据库手动插入一条用户记录时，生成符合应用格式的 Bcrypt 密码哈希。
- 验证登录逻辑 — 用明文和库里存的哈希做匹配，确认后端 compare 逻辑是否正确。
- 调优 cost 因子 — 在目标服务器上试不同 cost 值，找到验证耗时与安全的平衡点。
- 排查迁移问题 — 系统迁移后核对老哈希是否仍能被新代码正确校验。
- 审查存储格式 — 检查现有哈希字符串里的版本前缀（2a/2b）与盐是否规范。
常见问题
为什么同一密码每次生成的哈希都不同？
因为 Bcrypt 每次都用新的随机盐，盐被编码进哈希字符串本身。验证时算法会从哈希里读出盐重新计算，所以哈希不同不代表错误，依然能正确匹配。
cost 因子设多少合适？
cost 每加 1，计算量翻倍。常见取值 10-12；应在生产硬件上调到单次哈希约 100-300 毫秒，既挡住暴力破解又不拖垮登录体验。
Bcrypt 有长度限制吗？
有。Bcrypt 只处理输入的前 72 个字节，超出部分被忽略。若需支持超长密码，常见做法是先用 SHA-256 预哈希再交给 Bcrypt。
Bcrypt 和 SHA-256 能互换吗？
不能用于存密码。SHA-256 速度极快，反而利于攻击者爆破；Bcrypt 故意慢且带盐，是密码存储的正确选择，SHA-256 更适合做完整性校验。
2a、2b、2y 前缀有什么区别？
它们是 Bcrypt 的版本标识，因历史上的实现 bug 而分化。现代库默认用 2b，最为规范；只要库支持，旧前缀的哈希通常仍可正常验证。
校验时提示无效的盐或直接判定失败，怎么排查？
多数情况是存储时哈希串被截断了。完整串包含算法标识、工作因子、盐与摘要四段，必须整串存取；若数据库列长度不足（常见是只给了六十个字符而实际更长），写入时会被静默截断，读取后自然校验失败。排查方法是先确认数据库里实际保存的字符串长度与生成时逐字节一致，再怀疑算法或参数。
同样的工作因子，为什么换台机器后校验速度差很多？
工作因子决定计算轮数，实际耗时由硬件决定，新处理器通常比旧机器快数倍，而某些合规要求会启用更保守的实现从而变慢。安全上的目标不是某个固定轮数，而是让单次校验维持在约一百毫秒量级，因此应随硬件升级调整轮数，而不是把当前数值当成永久标准；调整后旧哈希仍可校验，可借用户下次登录时逐步重算。
cost 因子（rounds）设多少合适？
默认 10 在现代硬件上约几十毫秒，适合大多数登录场景；每 +1 计算时间翻倍。登录接口 10–12 是常见区间，再高会把注册/登录拖到秒级且方便 DoS。确定后不要频繁调整——改 cost 会让旧哈希逐步失效，需要平滑迁移。