JavaBCrypt加密教程详解

本文深入剖析了Java中BCrypt密码加密在Spring Security实践中的关键陷阱与最佳实践：默认强度10虽安全却易引发高并发下CPU飙升，推荐显式配置strength=11以平衡性能与安全性；必须严格使用passwordEncoder.matches()进行恒定时间比对，杜绝字符串直接比较以防时序攻击；Spring Boot 3起必须手动声明PasswordEncoder Bean并添加{bcrypt}前缀以适配DelegatingPasswordEncoder机制；同时需警惕BCrypt固有的72字节密码长度限制和空密码问题，务必在业务层前置校验。掌握这些细节，才能真正用好BCrypt，兼顾安全、稳定与可维护性。

BCryptPasswordEncoder 默认强度是 10，别直接用 new BCryptPasswordEncoder()

Spring Security 的 BCryptPasswordEncoder 默认构造函数设的是强度 10，但很多项目上线后才发现：这个值在高并发登录场景下 CPU 占用突增，尤其容器资源受限时容易触发超时。不是不够安全，而是“默认”不等于“适合你”。

• 强度每 +1，计算耗时约翻倍；强度 12 在普通云主机上单次 encode 可能达 250ms+
• 若旧系统迁移，必须记录当时使用的 strength 值，否则无法校验老密码
• Spring Boot 2.7+ 中，new BCryptPasswordEncoder() 和 new BCryptPasswordEncoder(10) 行为一致，但显式写出更利于审计
• 推荐做法：new BCryptPasswordEncoder(11)（平衡安全与响应）或根据压测结果定值，写死在配置类里

passwordEncoder.matches() 是唯一合法的密码比对方式

别手写字符串比较，也别把 encode() 结果拆开比对盐值——BCrypt 的验证逻辑封装在 matches() 里，它会自动提取哈希中的盐、重算并恒定时间比对，防时序攻击。

• 错误示范：user.getPassword().equals(encoder.encode(raw)) —— 永远 false，且泄露处理逻辑
• 错误示范：rawPassword.equals(storedHash) —— 明文比密文，毫无意义
• 正确调用：passwordEncoder.matches(rawPassword, storedHash)，其中 storedHash 是数据库里存的完整 BCrypt 字符串（形如 $2a$11$...）
• 注意：matches() 内部会解析 storedHash 的版本号（$2a$/$2b$/$2y$），Spring Security 5.8+ 默认生成 $2a$，但兼容全部

Spring Boot 3.x 起，BCryptPasswordEncoder 不再是默认 PasswordEncoder

Boot 3 引入了 DelegatingPasswordEncoder，启动时若没显式配置，会抛 IllegalArgumentException: There is no PasswordEncoder mapped for the id "null"。这不是 bug，是强制你声明策略。

• 原因：支持多算法共存（比如部分用户用 BCrypt，部分用 SCrypt），靠前缀识别，如 {bcrypt}$2a$10$...
• 必须在配置类中定义 Bean：@Bean public PasswordEncoder passwordEncoder() { return new BCryptPasswordEncoder(11); }
• 如果沿用旧库（如 Spring Security 5.x 的 XML 配置习惯），漏掉这步，应用根本启不来
• 数据库里存的哈希值建议统一加前缀：{bcrypt}$2a$11$...，这样即使未来切换策略，也能靠前缀路由

BCrypt 不支持空密码和超长密码（72 字节截断）

这是 BCrypt 算法层限制，不是 Spring 封装的问题。传入超过 72 字节的原始密码，会在 encode 前被静默截断，导致同样输入不同输出（比如 73 字节和 74 字节的密码可能 hash 相同）。

• 常见现象：用户输了一长串特殊符号密码，登录失败，但换短密码就成功——大概率是截断导致 hash 不匹配
• 解决方案：在 service 层做长度校验，例如 if (rawPassword.length() > 72) throw new IllegalArgumentException("Password too long");
• 空密码会被 encode 成固定值（$2a$10$XXXXXXXXXXXXXXXXXXXXXX...），虽然 matches() 能正确返回 false，但业务上应拒绝空值
• 别试图 Base64 或 SHA-256 预处理再喂给 BCrypt——破坏盐的随机性，且无实际收益

BCrypt 的盐是每次 encode 自动生成并嵌入结果的，你没法也不该干预它的生成逻辑。真正要盯住的，是 strength 值是否合理、hash 是否带前缀、比对是否走 matches，以及原始密码有没有踩到 72 字节那个隐形墙。

本篇关于《JavaBCrypt加密教程详解》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！