MySQL密码加密存储与查询实战：从bcrypt选型到JDBC集成

接手过一个老项目用户表里的password字段存的直接是明文。后来某天备份文件泄露几万条手机号和明文密码一起流出那场面至今想起来都头皮发麻。用户密码在 MySQL 里的加密存储、查询和验证算是每个后端开发者都绕不开的话题了但恰恰是这种“老生常谈”在实际开发里翻车率特别高。有人觉得把密码用 MD5 算一遍就算加密了有人觉得加密之后密码就没法查询了还有人直接在建表时留了个varchar(32)后来换算法时发现根本存不下。这篇文章基于我这些年做 MySQL 数据库设计、用户认证模块改造的经验把两个核心问题彻底讲透一是密码加密方案怎么选、怎么落地到 MySQL 表结构和 JDBC/MyBatis 代码里二是密码加密之后在数据库层面到底还能不能查询、怎么查询、哪些查询方向从一开始就不该碰。适合正在写用户系统的后端开发、需要重构老项目的同学以及被运维追问“为什么用户表密码字段是乱码”的入门朋友。1. 先搞清楚你的“加密”属于哪一种决定了后续查询的方式1.1 很多人对“加密”的理解是错的在做任何技术选型之前我必须先把概念掰开揉碎。MySQL 数据库密码存储这个场景里大家口头说的“加密”其实分成两条完全不同的技术路线。第一条是单向哈希Hash比如 MD5、SHA-256、bcrypt、scrypt、Argon2。它只能从明文算到密文理论上不可逆你没有办法从哈希结果还原出原始密码。第二条是可逆加密比如 AES-256-GCM用一把密钥加密拿到密钥就可以解密回明文。这两种路线在“查询”上的表现完全不同。可逆加密意味着密文可以解密理论上你想搜索明文密码是能做到的但代价是必须把密钥管理好一旦密钥泄露整个用户表等于裸奔。单向哈希意味着密文永远不可逆你只能做“比对”不能做“搜索”。很多开发者在设计表结构的时候根本没有想清楚走的是哪条路线导致后面加查询功能时进退两难。我这里先给一个贯穿全文的原则用户密码首选单向哈希尤其是 bcrypt 这类专门为密码设计的慢哈希算法。MySQL 里存密码不是为了系统“知道”密码是什么而是为了在用户登录时“验证”提交的密码是否正确。这个区别是整篇文章的地基后面所有关于查询的讨论都建立在这句话上。1.2 为什么 MD5 和 SHA1 不能拿来直接存密码为什么要单独说 MD5因为直到今天依然有大量老项目在用 MD5 存密码。我见过不止一个团队技术栈很新Spring Boot 3 Redis 集群都用上了用户密码却是MD5(password)一把梭。MD5 的问题有三个每一个都是致命的。第一没有盐。相同的密码会生成完全相同的哈希值攻击者只需要准备一份彩虹表把常见密码的哈希预先算一遍拿到数据库之后一比对就能批量还原。第二计算速度太快。现代 GPU 每秒可以算几十亿次 MD5你的用户密码只要不是 30 位以上的随机串暴力破解成本低到可以忽略。第三哈希值固定 32 位十六进制本身并不提供额外安全性哪怕你把它截断、拼接、二次哈希只要算法设计是“快”攻击者就可以用同样的速度暴力还原。有人会说那我用MD5(password salt)不就行了吗这种做法比裸 MD5 好但问题在于盐的拼接方式很容易被攻击者猜出来而且你仍然没有解决“计算太快”这个根本缺陷。与其在盐的拼接规则上反复发明轮子不如直接用 bcrypt。bcrypt 把随机盐的生成、与口令的混合、多轮计算全部标准化了你不需要自己设计任何东西。2. 方案选型的底层逻辑先回答“密码要不要能还原”2.1 主流算法的横向对比与真实适用场景我整理了一张表把主流方案放在一起对比方便你在做技术评审时直接拿去用算法方向是否可逆推荐程度适用场景MD5单向哈希不可逆不推荐新建使用历史存量系统尽快迁移SHA-256单向哈希不可逆可用于数据指纹不建议直接存用户密码文件校验、针对固定盐的接口签名bcrypt单向慢哈希不可逆推荐作为默认方案绝大多数 Web 系统的用户密码存储scrypt单向慢哈希不可逆推荐需要进一步抵抗 GPU/ASIC 暴力破解的高安全场景Argon2单向慢哈希不可逆当前综合抗性最强登录频率低、安全等级要求高的系统AES-256-GCM可逆加密可逆仅在特殊业务下使用需要明文回显密码的内部管理系统、对接老系统的账号托管表格里最后一行值得多说两句。AES 不是不能用而是它解决的是另一个问题。如果你把用户密码用 AES 加密那就意味着系统具备还原明文的能力你必须额外承担密钥管理的责任。我的实践结论是除非有明确的产品需求比如管理员需要查看用户密码明文、客服代下单要验证原始密码否则不要走可逆路线。绝大多数互联网产品的用户密码不需要任何人“看到明文”。2.2 为什么 bcrypt 是默认选项bcrypt 的内部机制有几个关键参数输入口令、随机盐、成本因子cost。它会基于 Blowfish 算法进行 2 的 cost 次方轮次的迭代计算cost 默认取 10 时单次哈希大约需要几十到一百毫秒。这个时间粒度非常巧妙——对正常用户来说登录时多等几十毫秒毫无感知对攻击者来说想在一年内批量爆破几百万条哈希算力成本会呈指数级上升。我用一个生活类比解释给你听MD5 是一把秒开的锁碰一下锁芯就转了bcrypt 是一把每次都要咔嗒咔嗒转几十圈的锁。前者方便了开锁的人也方便了小偷后者让小偷即使偷走了整个锁芯面对几千把锁也只能一把一把慢慢磨磨到他自己先放弃。实测中我推荐把 bcrypt 的 cost 设在 10 到 12 之间。低于 10 安全性偏弱高于 12 纯软件环境下延迟会比较明显尤其是高并发登录场景每次登录多 300 毫秒也是成本。这个值应该根据你们服务器的 CPU 性能做压测后确定不是越大越好。2.3 可逆加密的合法场景和底线我并不是完全反对可逆加密。某些内部管理系统比如客服工作台需要查看用户账号的原始密码以便代客登录或者老系统对接时需要把密码传给第三方这时候 AES-256-GCM 是合理的。这类场景我一般要求做到三点密钥放在配置中心或 KMS不写死在代码和配置文件中每个用户记录里保存密钥版本号方便密钥轮换审计日志记录谁在什么时候解密查看了密码。但我要强调这属于例外情况不是常规操作。一旦系统具备了“还原密码”的能力数据库泄露的性质就从“哈希泄露”升级为“明文密码泄露”影响完全不同。如果产品经理没有明确要求不要去主动增加这个能力。3. 从建表到 JDBC 集成一套可以直接落地的密码存储方案3.1 表结构设计字段命名、字符集、长度方案定了接下来就是建表。先给一个我常用的表结构CREATE TABLE user ( id bigint unsigned NOT NULL AUTO_INCREMENT, username varchar(64) NOT NULL COMMENT 登录名, password_hash varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin NOT NULL COMMENT bcrypt哈希结果, password_version tinyint NOT NULL DEFAULT 2 COMMENT 密码算法版本1MD5, 2bcrypt(md5), 3bcrypt, created_at datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, updated_at datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_username (username) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这里有几个细节值得说道。字段名用password_hash而不是password避免后续同事一看到password字段就误以为是明文密码随手 select 出来打日志。bcrypt 哈希输出通常 60 个字符但考虑到未来可能切换算法varchar(255)是稳妥的选择也给算法升级留了空间。排序规则用utf8mb4_bin保证哈希字符串的等值比较是二进制级别的不参与 MySQL 的字符集大小写转换避免一些诡异的匹配问题。3.2 Spring Boot 配合 spring-security-crypto在实际项目里我最常用的组合是 Spring Boot spring-security-crypto。这个库独立于完整 Spring Security只提供密码学工具不会引入一堆拦截器轻量且安全。先在pom.xml里加依赖dependency groupIdorg.springframework.security/groupId artifactIdspring-security-crypto/artifactId version6.3.1/version /dependency然后声明一个BCryptPasswordEncoder的 BeanConfiguration public class PasswordConfig { Bean public BCryptPasswordEncoder passwordEncoder() { return new BCryptPasswordEncoder(10); } }注册用户时加密入库Transactional public void register(String username, String rawPassword) { if (userMapper.existsByUsername(username)) { throw new BusinessException(用户名已存在); } User user new User(); user.setUsername(username); user.setPasswordHash(passwordEncoder.encode(rawPassword)); user.setPasswordVersion(3); userMapper.insert(user); }登录校验时拿用户输入的原始密码和数据库里的哈希做比对public boolean verifyPassword(String rawPassword, User user) { return passwordEncoder.matches(rawPassword, user.getPasswordHash()); }注意matches内部会自动从哈希字符串中提取盐和 cost 参数不需要你手动处理。这也是 bcrypt 比自研加盐方案舒服的地方——盐跟哈希一起存储校验时自动读取。3.3 非 Spring 项目用 jBCrypt 手工封装如果你的项目没有引入 Spring比如纯 Java Web、Play Framework、或者公司自研的轻量框架可以直接使用jBCrypt库。这个库非常小依赖少核心只有两个静态方法import org.mindrot.jbcrypt.BCrypt; public class PasswordUtil { public static String encode(String rawPassword) { // 第二个参数是 salt 的复杂度默认 10 return BCrypt.hashpw(rawPassword, BCrypt.gensalt(10)); } public static boolean matches(String rawPassword, String encodedPassword) { return BCrypt.checkpw(rawPassword, encodedPassword); } }注册时执行PasswordUtil.encode(rawPassword)登录时执行PasswordUtil.matches(rawPassword, user.getPasswordHash())就这么简单。工具里最好把 cost 定义成常量将来调参只需要改一处。3.4 进阶自定义 MyBatis TypeHandler 自动加解密如果你们项目里用户写入和校验散落在多个 Service可以在 MyBatis 层封装一个 TypeHandler让密码加解密对业务代码透明。自定义 TypeHandler 的思路是写入时自动加密查询时不自动解密单向哈希场景下读到密文仅供比对。一个简化的实现如下MappedTypes(String.class) MappedJdbcTypes(JdbcType.VARCHAR) public class PasswordTypeHandler extends BaseTypeHandlerString { Override public void setNonNullParameter(PreparedStatement ps, int i, String parameter, JdbcType jdbcType) throws SQLException { // 写入时统一加密 ps.setString(i, BCrypt.hashpw(parameter, BCrypt.gensalt(10))); } Override public String getNullableResult(ResultSet rs, String columnName) throws SQLException { // 读取时直接返回哈希值不做解密 return rs.getString(columnName); } Override public String getNullableResult(ResultSet rs, int columnIndex) throws SQLException { return rs.getString(columnIndex); } Override public String getNullableResult(CallableStatement cs, int columnIndex) throws SQLException { return cs.getString(columnIndex); } }然后在 XML 映射文件里指定resultMap iduserResultMap typeUser result columnpassword_hash propertypasswordHash typeHandlercom.example.handler.PasswordTypeHandler/ /resultMap这个方案的好处是统一坏处是隐蔽。我建议只在项目里一个人明确负责密码安全时采用这种自动拦截否则一旦出现“查询用户的时候密码自动加密了一遍”这种隐性坑排查起来非常难受。多数项目我反而推荐业务层显式调用passwordEncoder.encode()代码可读性更好。4. 加密之后的“查询”难题哪些能查哪些不能查怎么查4.1 登录验证的标准链路与时间侧信道规避密码哈希之后最核心的查询就是登录验证。你需要在 MySQL 里先按username查到用户记录再在应用层用 bcrypt 比对提交的密码和库里的哈希。SQL 很简单SELECT id, username, password_hash, password_version FROM user WHERE username #{username} LIMIT 1;然后应用层做校验。这里有一个很多人忽略的细节当username查不到用户时响应时间会明显短于查得到用户时的 bcrypt 比对耗时攻击者可以利用这个时间差判断某个用户名是否存在这就是常见的时间侧信道。规避方式是在查不到用户时也执行一次假的 bcrypt 比对public LoginResult login(String username, String rawPassword) { User user userMapper.findByUsername(username); // 预先准备好的一个固定哈希只用于时间对齐 if (user null) { passwordEncoder.matches(rawPassword, DUMMY_HASH); return LoginResult.fail(用户名或密码错误); } if (!passwordEncoder.matches(rawPassword, user.getPasswordHash())) { return LoginResult.fail(用户名或密码错误); } return LoginResult.success(user); }这样做之后用户不存在和密码错误两种情况的响应时间基本一致攻击者无法通过延迟精确枚举用户名。这个小细节很多团队不做但它属于零成本高收益的安全加固非常推荐。4.2 为什么不能直接用 password_hash 做等值搜索很多开发者在设计“密码查询”功能时第一反应是把用户输入的密码也用同样的算法加密一次然后去数据库里 where 比较。这个思路在 MD5 时代勉强可行因为固定盐或者无盐的 MD5 哈希值是稳定的但在 bcrypt 这里完全行不通。bcrypt 每次计算都会生成一个全新的随机盐也就是说同一个明文密码加密两次得到的哈希值完全不同。你拿着新算出来的哈希值去数据库里找永远匹配不到任何记录。这也是为什么 bcrypt 哈希列即使加了普通 B-tree 索引也无法支持基于“已知明文推算哈希”的等值查询——因为你根本算不出那个已经在数据库里的确定哈希值。如果业务上确实存在“外部系统回传一个哈希值需要在用户表里反查用户”这种需求我的做法是把 bcrypt 哈希再算一次 SHA-256 摘要单独存一列加唯一索引ALTER TABLE user ADD COLUMN password_hash_sha256 char(64) DEFAULT NULL COMMENT 用于快速反查的哈希摘要, ADD UNIQUE KEY uk_password_hash_sha256 (password_hash_sha256);写入时同时对password_hash和password_hash_sha256赋值。查询时先对输入的哈希值做 SHA-256然后走索引匹配。这样既保留了 bcrypt 的安全强度又获得了一个可索引的稳定查询键。4.3 AES 可逆方案下的查询边界如果某个系统因为业务原因用了 AES-256-GCM数据库里存的是一段密文这时候查询问题同样复杂。很多人会把解密函数写进 SQL比如用AES_DECRYPT()在 where 里比较我强烈不建议这样做原因有两个第一MySQL 内置的加解密函数性能和密钥管理都很尴尬密钥会出现在 SQL 日志里第二现代 AES 加密通常带随机初始化向量IV相同明文每次生成的密文都不同你根本无法在 SQL 里直接用等值比较命中。我的落地经验是把查询能力从“密码内容”迁移到“业务主键”上。例如管理员需要根据手机号查用户那就单独维护mobile_encrypted和mobile_sha256两个字段前者用于展示时解密后者用于查询时匹配。密码本身极少数需要按内容检索的场景都交给应用层从缓存或离线索引里去处理绝不让数据库参与解密计算。4.4 模糊搜索是禁区为什么最后想说一个存在但应该被否定的需求密码的模糊搜索。总有业务方提“我想查一下有哪些用户的密码是 123456”或者“找一下密码包含生日数字的用户”。我可以负责任地告诉你在单向哈希方案下这是不可能实现的在可逆加密方案下这几乎等于在裸奔。密码字段的定位是认证凭证不是业务数据。它不应该参与任何形式的统计分析、模糊匹配、区间查询。如果产品真的需要了解用户的密码习惯正确方式是做数据清洗比如导入已知弱密码库然后引导用户修改密码而不是去搜索明文或尝试解密。这是安全底线也是我在技术上最坚持的原则之一。5. 我踩过的几个真实坑从乱码到存量迁移再到日志泄露5.1 字段长度不够与排序规则选错最早接手的遗留系统里password字段是varchar(32)存 MD5 刚合适。后来要做安全升级换成 bcrypt第一个晚上线上就报数据截断异常——bcrypt 哈希 60 个字符32 个字符的字段根本写不进去。那次升级让我学到了一个习惯凡是密码哈希字段一律给varchar(255)不要精打细算省那几十个字节。排序规则也有坑。如果表用的是utf8mb4_general_ciMySQL 在做字符串比较时是不区分大小写的而 bcrypt 哈希恰好是大小写敏感的。理论上哈希字符串如果包含字母排序规则会在某些边界情况下影响索引查询和唯一性判断。为了彻底消除这个隐患我后来建表时密码字段一律显式指定COLLATE utf8mb4_bin让哈希值的比较走二进制规则跟应用层 Java 的equals保持一致。5.2 SQL 日志和慢查询日志把哈希打出去的尴尬有段时间排查线上问题我给 MyBatis 开了 stdout 日志结果整条 SQL 和参数都被打到了应用日志里其中就包括每次登录传进来的原始密码。日志系统再接入 ELK等于把用户密码的哈希值甚至部分明文痕迹分发到了各个内部系统。后来团队整改把 MyBatis 的 SQL 日志改成了只打印 SQL 不打印参数或者干脆在生产环境关掉 SQL 日志mybatis: configuration: log-impl: org.apache.ibatis.logging.nologging.NoLoggingImpl如果你用 Druid 连接池也要注意它的 SQL 日志输出里面同样会带参数。排查问题时可以临时开但上线前必须确认日志里不会残留完整的密码相关字段。5.3 MD5 存量数据怎么平滑升级到 bcrypt老系统的用户表里全是MD5(password)直接改成 bcrypt 会让所有老用户无法登录因为老哈希根本验不过。我用的平滑升级方案是“二次哈希”把原来的 MD5 值当作一个新密码再对它做 bcrypt。具体来说存量数据启动一个后台任务把每一条记录的MD5(password)值算出来再写入password_hash bcrypt(md5(password))并把password_version标记为 2。登录校验时按版本分流的逻辑如下if (user.getPasswordVersion() 1) { // 旧版纯 MD5先核验 if (md5(rawPassword).equalsIgnoreCase(user.getOldPasswordMd5())) { // 核验通过立即升级为 bcrypt(md5(password)) String md5Value md5(rawPassword); user.setPasswordHash(BCrypt.hashpw(md5Value, BCrypt.gensalt(10))); user.setPasswordVersion(2); userMapper.updatePasswordHash(user); return true; } return false; } if (user.getPasswordVersion() 2) { // 存量升级后的方案先算 md5 再 bcrypt 比对 return BCrypt.checkpw(md5(rawPassword), user.getPasswordHash()); } // 新用户直接 bcrypt return BCrypt.checkpw(rawPassword, user.getPasswordHash());这个方案我实际落地过用户完全无感知不用批量重置密码也不用存两份哈希。更重要的是password_version这个字段让我后续做算法轮换时只需要在登录校验时分流到不同算法不需要跑全量数据后台慢慢重算更新即可。5.4 区分两类“密码加密”用户口令加密与数据库连接密码加密最后提醒一个容易混淆的概念。网上很多搜“MySQL 数据库密码加密”的文章讲的是 Druid 对 JDBC 连接串里的数据库密码进行加密解决配置文件泄露问题而本文讨论的是应用层对用户口令的加密存储。两者完全不同前者是运维层面的凭据保护核心工具是 Druid 的ConfigFilter后者是业务安全设计核心是 bcrypt/AES 的选择与查询策略。如果你在一个基于若依框架或其他集成 Druid 的系统里做改造先确认你面对的到底是哪一类需求。我之前见过同事把 Druid 连接密码加密配置研究了一下午结果发现产品要求的是用户密码加密方向完全跑偏。这两件事可以同时做但方案和代码完全不在一个层面。最后补充一点个人经验密码加密这件事真正难的不是选择算法而是持续演进。我给所有新项目建用户表时都会放一个password_version字段记录这条哈希是用哪个算法生成的。这个字段看起来不起眼但当你三年后需要从 bcrypt 切到 Argon2或者发现某批存量用户哈希强度不够时它会帮你省掉一场灾难级别的数据迁移。登录校验时分流、后台批量重算都需要这个字段作为判断依据。说实话我也曾在没有这个字段的旧项目里吃过亏后来再也不敢省了。