Spring Security 这个框架几乎每个做 Java 后端的人都会跟它打交道。很多人第一次接触它都是从“内存用户”开始的在配置类里写死一两个用户名和密码登录页面输进去验证通过完了。但等真正接手企业项目你会发现内存用户连玩具都算不上。真实系统里用户存在数据库里、密码不能是明文、权限要按角色区分、不同环境还要能动态配置。这篇就是围绕这个进阶过程来写的核心目标只有一个把 Spring Security 的认证数据源从内存用户切换到数据库同时把密码从明文彻底换成 BCrypt 哈希。文章会依次讲清楚为什么内存用户撑不起真实业务、密码加密为什么不能停留在“看起来不像明文”的水平、数据库认证的完整实现步骤、一次登录请求背后到底发生了什么以及我实际踩过的坑和排查思路。适合两类人一类是刚用 Spring Security 做过简单登录、想往企业级项目靠的初学者另一类是接手老系统、想把内存用户或明文密码改造成规范方案的开发者。跟着做完你会得到一套能直接跑的数据库认证示例也会明白每个配置和依赖背后的原因而不是只会复制粘贴。1. 项目整体设计与思路拆解1.1 内存用户为什么只能当入门玩具先看一段最常见的内存用户写法Bean public UserDetailsService users() { UserDetails admin User.withUsername(admin) .password({noop}123456) .roles(ADMIN) .build(); UserDetails user User.withUsername(user) .password({noop}123456) .roles(USER) .build(); return new InMemoryUserDetailsManager(admin, user); }这段代码本身没有语法问题跑起来也能登录但在真实项目中会有一堆问题。第一账号密码硬编码在代码里改密码要改代码、重新编译、重新部署这在运维上是不可接受的。第二所有环境共用同一套账号开发、测试、生产没有任何隔离存在明显的安全隐患。第三内存用户无法支持用户自主注册、修改密码、找回密码。第四团队协作时如果密码不小心提交到 Git基本等于把入口拱手送人泄露路径还特别隐蔽。所以内存用户适合什么场景适合本地调试、单元测试、给前端联调临时开个账号。一旦系统要上线、要面向真实用户就必须把用户数据挪到数据库里这是企业项目的底线。1.2 切换到数据库用户的三个核心变化从内存用户切到数据库用户表面上只是改了一个 UserDetailsService 实现实际上是三个层面的变化。第一层是数据源发生变化。UserDetailsService 不再是返回一个写死的用户而是到数据库表里查用户记录。为了支撑这个变化需要建用户表、需要实现按用户名查询的方法。第二层是密码存储与校验方式发生变化。内存用户阶段可以偷懒用{noop}表示不加密但数据库方案一定要升级为 BCrypt 这类不可逆哈希因为数据库一旦泄露明文密码等于批量泄露。第三层是认证链路发生变化。之前 InMemoryUserDetailsManager 自己内部就处理完了切到数据库之后Spring Security 的 DaoAuthenticationProvider 会调用我们实现的 UserDetailsService 加载用户再用 PasswordEncoder 校验密码链路比以前长但每个环节都可控。这里可以列个简单的演进对比方案用户存储密码形式可注册生产可用内存用户内存Map明文或Noop不支持否数据库MD5数据库表MD5散列支持勉强但不推荐数据库BCrypt数据库表随机盐慢哈希支持推荐演进到数据库认证之后下一步就是密码加密方案的选型。这两件事是绑在一起的只改数据库不换加密等于换汤不换药。1.3 整体架构与项目准备本文示例采用 Spring Boot 3 作为基础框架Spring Security 6 作为安全框架数据访问用 Spring JDBC 的 JdbcTemplate。之所以不引入 MyBatis 或 JPA是为了把注意力集中在 Security 本身少一层 ORM 的干扰。实际项目中你用 MyBatis-Plus 还是 Spring Data JPA 都不影响这套认证逻辑的落地UserDetailsService 里的查询换成任何 ORM 写法都行。项目依赖只需要四个核心模块spring-boot-starter-web提供 Web 容器和接口能力。spring-boot-starter-security提供安全认证和授权能力。spring-boot-starter-jdbc提供数据库访问。mysql-connector-j或对应数据库驱动连接 MySQL。至于表结构建一张sys_user表是最基本的要求字段包括主键、用户名、密码哈希、昵称、状态、创建时间等。2. 密码加密不能只做到“看不清”2.1 明文密码到底有多危险很多人有个错觉觉得密码存在数据库里只要做不了 SQL 查询别人就看不到。但数据库泄露从来不是“能不能看到”的问题而是“多长时间能看到”的问题。明文密码一旦落入攻击者手里不仅是当前系统失守用户如果在其他平台用了同一个密码连锁反应会波及邮箱、支付、社交账号。这个叫撞库是黑色产业里最常见的一条路径。就算不泄露明文密码在内部也有风险。运维同事能查到所有人的密码离职员工可能留着数据库备份第三方排查问题时顺手看到。安全领域有个原则叫“最小知识原则”意思是每个人只应该知道完成工作所必需的信息。密码这个东西连用户自己都不该被提醒更不该被系统保存成可读的原始字符串。2.2 MD5 为什么被安全社区“嫌弃”有人会说那我把密码用 MD5 加密一下再存数据库不就行了吗MD5 确实不是明文但它远远不够。MD5 的问题有三个。第一MD5 是一种快速哈希算法计算速度极快攻击者可以用 GPU 在短时间内跑海量组合配合字典和规则碰撞出原始密码。第二MD5 固定盐或者不加盐时相同密码会得到相同哈希攻击者可以预先用彩虹表建立哈希到明文的映射查表就能反推出密码。第三MD5 本身被发现了碰撞漏洞虽然对密码存储场景的影响没有前面两个那么直接但业界早已不推荐在密码领域继续使用。给 MD5 加盐能解决彩虹表问题但只要是普遍使用的快哈希暴力枚举成本依然很低。密码加密的正确思路不是“算得快”而是“算得慢”。慢到攻击者枚举一次要耗费巨大算力同时又不能慢到用户登录体验不可接受。2.3 BCrypt 到底做了什么BCrypt 是目前 Spring Security 官方推荐的密码哈希方案它之所以能站稳脚跟靠的是三个设计。第一它是基于 Blowfish 加密算法的自适应哈希函数输出结果中会带上随机盐和强度因子。这意味着即使两个人密码完全相同每次算出来的哈希字符串也不一样彩虹表直接失效。第二它的计算强度是可调的。默认强度是 10表示要进行 2 的 10 次方轮迭代可以根据服务器性能调高。第三它的输出格式自带信息比如$2a$10$...这段字符串里2a表示算法版本10表示强度后面的 22 个字符是盐再往后才是真正的哈希值。Spring Security 在验证时只需要读取哈希字符串本身就能知道用的是什么参数所以同一个系统里允许存在不同强度、不同算法的密码这在老系统迁移时特别有用。2.4 PasswordEncoder 家族与选择建议Spring Security 5 之后官方默认的 PasswordEncoder 是DelegatingPasswordEncoder它不是某个具体的算法而是一个“代理”通过前缀来识别使用哪种算法。比如{bcrypt}前缀表示 BCrypt{noop}表示不加密{MD5}表示 MD5。你可能会问为什么搞这么复杂直接全部换成 BCrypt 不就行了关键在升级场景。一个老系统里可能并存着不同时期注册的密码有些是 MD5有些是明文如果直接一刀切改成 BCrypt所有老用户全部登录失败。DelegatingPasswordEncoder可以在验证时兼容多种格式同时又支持把新密码统一存为 BCrypt 格式实现平滑过度。所以我的建议很明确新项目直接用 BCrypt不要犹豫。老项目要改造用DelegatingPasswordEncoder兜底逐步把老哈希迁移成 BCrypt。3. 从内存用户到数据库用户的核心实操3.1 数据库表设计与建表 SQL认证表不需要设计得多复杂核心字段围绕“用户唯一标识”“密码哈希”“账号状态”来定CREATE TABLE sys_user ( id BIGINT AUTO_INCREMENT PRIMARY KEY, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(100) NOT NULL, nickname VARCHAR(50) DEFAULT , status TINYINT DEFAULT 1, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP );这里有几个字段的设计讲究。username必须加唯一约束这是认证的前提重复用户名会导致 UserDetailsService 不知道该返回哪个用户。password字段建议长度不小于 60 个字符因为 BCrypt 哈希本身固定是 60 个字符加上前缀{bcrypt}后会更长如果设计成 32 个字符的字段存进去会被截断导致所有密码校验失败。status字段用来做账号禁用、冻结等状态控制返回的 UserDetails 里可以通过布尔值映射出来。3.2 实现 UserDetailsService 并加载数据库用户UserDetailsService 在 Spring Security 中扮演的角色就是“根据用户名查用户”。它唯一需要实现的方法就是loadUserByUsername(String username)。Service public class DatabaseUserDetailsService implements UserDetailsService { private final JdbcTemplate jdbcTemplate; public DatabaseUserDetailsService(JdbcTemplate jdbcTemplate) { this.jdbcTemplate jdbcTemplate; } Override public UserDetails loadUserByUsername(String username) throws UsernameNotFoundException { String sql SELECT username, password, nickname, status FROM sys_user WHERE username ?; ListMapString, Object rows jdbcTemplate.queryForList(sql, username); if (rows.isEmpty()) { throw new UsernameNotFoundException(用户不存在: username); } MapString, Object row rows.get(0); String password (String) row.get(password); boolean enabled Integer.valueOf(1).equals(row.get(status)); return User.withUsername(username) .password(password) .roles(USER) .disabled(!enabled) .build(); } }注意这里查询用了?占位符而不是字符串拼接就是为了从一开始就防住 SQL 注入。很多人觉得 SQL 注入是老生常谈但在真实项目里由于赶工或不注意拼接 SQL 的情况依然不少。Spring Security 的认证过程会把你传入的用户名直接交给 UserDetailsService 处理如果用户名拼进 SQL攻击者就能在登录接口上做文章。这里角色我先统一写死为USER实际系统一般会引入角色表和用户角色关联表但这和认证链路无关不展开也能跑通。3.3 配置 SecurityConfig 与密码编码器接下来是把自定义的 UserDetailsService 接入 Spring Security 的配置。以下是一个最简的可运行配置Configuration EnableWebSecurity public class SecurityConfig { private final DatabaseUserDetailsService userDetailsService; public SecurityConfig(DatabaseUserDetailsService userDetailsService) { this.userDetailsService userDetailsService; } Bean public PasswordEncoder passwordEncoder() { return new BCryptPasswordEncoder(); } Bean public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception { http .authorizeHttpRequests(auth - auth .requestMatchers(/login, /register).permitAll() .anyRequest().authenticated() ) .formLogin(form - form .loginPage(/login) .permitAll() ) .logout(logout - logout.permitAll()) .userDetailsService(userDetailsService) .csrf(csrf - csrf.disable()); return http.build(); } }有两点要注意一下。一是userDetailsService(...)这个方法。虽然 Spring Security 会自动从容器里找 UserDetailsService但为了明确最好显式设置。不设置的风险是当容器里有多个 UserDetailsService 或存在自定义认证逻辑时容易出现“到底用哪个”的歧义。二是csrf.disable()。生产环境拆不拆要看你的实际交互方式。如果是前后端分离、走 Token 认证CSRF 防护可以关掉如果是传统表单登录、依赖 Session打开 CSRF 更稳妥代价是登录表单里要带上 token。示例中先关掉方便调试接口。3.4 注册接口密码从明文变成 BCrypt 哈希数据库切换不能只改登录还要考虑新用户怎么进去。如果注册接口把密码明文存了登录再安全也白搭。下面是一个简单的注册接口RestController public class AuthController { private final JdbcTemplate jdbcTemplate; private final PasswordEncoder passwordEncoder; public AuthController(JdbcTemplate jdbcTemplate, PasswordEncoder passwordEncoder) { this.jdbcTemplate jdbcTemplate; this.passwordEncoder passwordEncoder; } PostMapping(/register) public String register(RequestBody RegisterRequest request) { String encodedPassword passwordEncoder.encode(request.password()); jdbcTemplate.update( INSERT INTO sys_user (username, password, nickname) VALUES (?, ?, ?), request.username(), encodedPassword, request.nickname() ); return 注册成功; } }密码在这里先通过PasswordEncoder.encode()转换成 BCrypt 字符串再写进数据库。这一步是目前为止最重要的一行代码。注册时如果不做加密后续所有安全设计都存在最脆弱的环节。可以实际打印一下 encode 出来的值形如$2a$10$CwT6TZ...每次执行结果都不一样但都能通过matches()方法验证成功。这就是 BCrypt 的随机盐在起作用。3.5 演示登录验证与数据库里的密码形态启动项目访问/login用注册好的账号登录。Spring Security 会自动读取表单中的 username 和 password交给 DaoAuthenticationProviderprovider 再调用我们实现的 DatabaseUserDetailsService 加载数据库用户最后用 PasswordEncoder 对输入密码和数据库中的 BCrypt 哈希做比对。如果一切正常登录成功后会跳到默认的/路径。此时打开数据库看一下sys_user表password 字段存储的绝对不是明文而是类似$2a$10$WnQ...的长字符串。到这里从内存用户到数据库用户的迁移就算完成了。4. 登录认证的完整流程与关键机制解析4.1 一次登录请求背后的完整链路很多初学者配置完之后能跑但说不清一次登录请求内部发生了什么。我把它拆成下面这条链路方便理解浏览器向/login提交用户名和密码请求先打到UsernamePasswordAuthenticationFilter。这个过滤器负责把请求参数封装成一个UsernamePasswordAuthenticationToken同时把未认证状态标记上去。接着这个 token 被交给AuthenticationManager在 Spring Security 中默认实现是ProviderManager。ProviderManager会遍历所有已注册的AuthenticationProvider找到能处理用户名密码认证的DaoAuthenticationProvider。DaoAuthenticationProvider先从UserDetailsService中加载用户数据加载不到就抛UsernameNotFoundException加载到了就把表单里的明文密码和数据库中的哈希交给PasswordEncoder.matches()比对一致则返回一个完整的认证对象不一致则抛BadCredentialsException。认证成功之后认证对象会存进 SecurityContext后续请求通过过滤器链就可以直接读取当前用户信息。这条链路拆开看并不复杂每个环节都有清晰的职责和扩展点。你想加验证码、加手机号登录、加多因素认证本质上就是在链路上的某个位置做自定义扩展。4.2 认证成功与失败从白标页面到 JSON 响应默认的表单登录在成功或失败之后是实现类自动重定向。搭建项目没问题但前后端分离时前端更期望收到 JSON 结构。在 Security 6 中可以这样定制.formLogin(form - form .loginProcessingUrl(/login) .successHandler((request, response, authentication) - { response.setContentType(application/json;charsetutf-8); response.getWriter().write({\code\:0,\message\:\登录成功\}); }) .failureHandler((request, response, exception) - { response.setContentType(application/json;charsetutf-8); response.setStatus(HttpServletResponse.SC_UNAUTHORIZED); response.getWriter().write({\code\:401,\message\:\用户名或密码错误\}); }) )这里有个容易被忽略的小坑一旦自定义了失败处理器异常类型就没有被框架吃掉你必须自己决定返回什么。如果是用户不存在、密码错误、账号禁用返回给前端的提示应该统一且模糊不要直接说“用户不存在”否则攻击者可以通过提示不断尝试用户名是否存在。推荐统一返回“用户名或密码错误”。4.3 会话管理与“记住我”表单登录默认会把认证信息放在 Session 里浏览器靠 Cookie 里的 Session ID 维持登录状态。这是经典方案也算稳定。需要注意的是一次性会话和并发登录控制.sessionManagement(session - session .maximumSessions(1) .maxSessionsPreventsLogin(true) )这个配置的含义是同一个用户只允许一个会话存在当新的会话建立时旧会话会被踢出或阻止新登录具体取决于maxSessionsPreventsLogin的值。这个功能在会员类系统里几乎是标配不然一个账号可以无限多地登录异常行为很难追踪。“记住我”功能原理是登录成功后生成一个持久化 Token存在数据库persistent_logins表里下次用户带这个 Token 回来就可以自动登录。这个功能不是安全重点但体验提升明显感兴趣可以单独研究。4.4 扩展方向前后端分离与无状态认证一旦做完数据库认证很多人下一步就会问Token 怎么做JWT 怎么集成Spring Security 本身不绑定会话或 JWT它给出的是一套认证机制你可以通过SecurityContextHolder来获取当前认证信息也可以在过滤器链上提前解析 Token 并手动把认证信息塞进去。我的建议是不要把 JWT 当成第一个优先方向先彻底搞懂 Session 认证和过滤器链的原理再去写 JWT 过滤器会顺手很多。原理通了JWT 只是换了一个“把认证信息放哪里”的载体。5. 常见问题与排查技巧5.1 密码明明正确就是登录失败这个现象出现频率极高。我用一个表格把常见原因和处理方法列出来现象大概率原因解决方案登录页面提示用户名或密码错误PasswordEncoder 类型不一致检查配置类里是否注册了 BCryptPasswordEncoder且没被覆盖数据库里密码有{noop}前缀但代码用 BCryptDelegatingPasswordEncoder 前缀未匹配统一统一前缀或用{bcrypt}存 BCrypt 哈希数据库密码字段长度不够BCrypt 哈希被截断修改字段长度到 80 以上重新存储密码新注册用户能登录老用户不能老用户密码还是明文或 MD5写迁移任务批量将老密码升级为 BCrypt有一种情况特别坑在某个类里手动new BCryptPasswordEncoder()而 SecurityConfig 里注入了另一个 PasswordEncoder导致注册时加密和登录时校验用的根本不是同一个实例。推荐整个工程都从容器里拿 PasswordEncoder不要到处 new。5.2 登录接口返回 403 而不是 401403 通常是权限不足401 是未认证。初学者经常遇到“明明登录逻辑没问题就是返回 403”的情况。常见原因有两个。第一是.requestMatchers(/login)没有放开。如果登录页本身也被拦截了请求还没走到认证过滤器就直接被拒绝。要确认 permitAll 的范围覆盖登录接口、静态资源和注册接口。第二是 CSRF 防护生效了。如果表单没有带_csrftokenSpring Security 会直接拒绝请求表现为 403。测试阶段可以先关掉 CSRF上线前再评估是否需要开启。5.3 循环依赖UserDetailsService 和 PasswordEncoder 互相引用有一种设计隐患是UserDetailsService 构造函数里注入 PasswordEncoder而 PasswordEncoder 又被放在 SecurityConfig 里SecurityConfig 又依赖 UserDetailsService。逻辑上绕了一圈容易引发循环依赖。建议把包含业务逻辑的 UserDetailsService 和纯配置的 PasswordEncoder 拆分清楚。比如 PasswordEncoder 单独放在一个Configuration类里UserDetailsService 只依赖 JdbcTemplate 或 Mapper不要让它反过来依赖安全配置类。这样既清晰也避免 Spring 启动时的循环依赖报错。5.4 老系统明文密码的迁移方案接手一个存量系统时你会发现数据库里既有明文、又有 MD5还有部分 BCrypt这是历史“成果”。直接一步切换到 BCrypt 会让大量用户登录失败怎么办最稳妥的做法是分两步走。第一步让系统在“验证”阶段兼容多种算法明文直接比较MD5 用 MD5 处理后比较BCrypt 用 matches。验证通过之后在“迁移”阶段把明文或 MD5 转换为 BCrypt。可以在每次成功登录时判断当前密码的编码方式如果不是{bcrypt}前缀就重新encode用户提交的明文密码并更新数据库。这样不用打扰用户迁移是在日常登录中悄悄完成的。5.5 几个提升体验的小细节第一个密码策略不能完全没有。至少要限制最小长度和复杂度BCrypt 只负责存储安全不负责用户密码强度。用 Spring Security 的PasswordValidator或自定义校验都可以。第二个登录接口要做限流和防暴力破解。BCrypt 本身很慢能够拖慢攻击速度但数据库查询和连接资源仍然会消耗。最简单的方案是在登录失败接口上做 IP 维度或用户名维度的失败次数限制连续失败多次就锁定一段时间。第三个不要再把敏感信息打印到日志里。登录失败时Spring Security 抛出的异常堆栈可能包含一些内部细节如果用全局异常处理器统一捕获记日志时注意不要把用户输入的明文密码打出来。写在最后的一些实际体会做这个改造的过程中我最大的体会是Spring Security 的难点不是配置怎么写而是搞清楚每个默认行为背后的设计意图。比如{noop}看起来只是给初学者用的但它其实揭示了 PasswordEncoder 的扩展机制理解了它就理解了为什么老系统可以平滑升级。再比如 BCrypt 的随机盐看似是“多此一举”实际是为了彻底瓦解彩虹表攻击。这些设计不是凭空来的每一个都是针对真实威胁的应对方案。如果让我给刚上手的人一个建议我不会让他先去背配置项而是让他把代码里所有密码相关的位置全部过一遍确保每一处写入数据库的密码都经过PasswordEncoder.encode()每一处校验都走matches()。这个底线守住Spring Security 的其他功能可以慢慢加安全问题不会在第一步就漏风。最后分享一个小技巧如果你只是想在本地快速联调又不想造数据库数据可以临时把内存用户的密码前缀保留为{noop}方便抓包观察登录流程。但凡是提交到远程分支、部署到公共环境务必换成 BCrypt走正规的数据库认证。用一句话总结我自己的态度登录功能可以很简单但密码的存放方式永远不能图省事。
Spring Security数据库认证实战：从内存用户迁移到BCrypt加密
Spring Security 这个框架几乎每个做 Java 后端的人都会跟它打交道。很多人第一次接触它都是从“内存用户”开始的在配置类里写死一两个用户名和密码登录页面输进去验证通过完了。但等真正接手企业项目你会发现内存用户连玩具都算不上。真实系统里用户存在数据库里、密码不能是明文、权限要按角色区分、不同环境还要能动态配置。这篇就是围绕这个进阶过程来写的核心目标只有一个把 Spring Security 的认证数据源从内存用户切换到数据库同时把密码从明文彻底换成 BCrypt 哈希。文章会依次讲清楚为什么内存用户撑不起真实业务、密码加密为什么不能停留在“看起来不像明文”的水平、数据库认证的完整实现步骤、一次登录请求背后到底发生了什么以及我实际踩过的坑和排查思路。适合两类人一类是刚用 Spring Security 做过简单登录、想往企业级项目靠的初学者另一类是接手老系统、想把内存用户或明文密码改造成规范方案的开发者。跟着做完你会得到一套能直接跑的数据库认证示例也会明白每个配置和依赖背后的原因而不是只会复制粘贴。1. 项目整体设计与思路拆解1.1 内存用户为什么只能当入门玩具先看一段最常见的内存用户写法Bean public UserDetailsService users() { UserDetails admin User.withUsername(admin) .password({noop}123456) .roles(ADMIN) .build(); UserDetails user User.withUsername(user) .password({noop}123456) .roles(USER) .build(); return new InMemoryUserDetailsManager(admin, user); }这段代码本身没有语法问题跑起来也能登录但在真实项目中会有一堆问题。第一账号密码硬编码在代码里改密码要改代码、重新编译、重新部署这在运维上是不可接受的。第二所有环境共用同一套账号开发、测试、生产没有任何隔离存在明显的安全隐患。第三内存用户无法支持用户自主注册、修改密码、找回密码。第四团队协作时如果密码不小心提交到 Git基本等于把入口拱手送人泄露路径还特别隐蔽。所以内存用户适合什么场景适合本地调试、单元测试、给前端联调临时开个账号。一旦系统要上线、要面向真实用户就必须把用户数据挪到数据库里这是企业项目的底线。1.2 切换到数据库用户的三个核心变化从内存用户切到数据库用户表面上只是改了一个 UserDetailsService 实现实际上是三个层面的变化。第一层是数据源发生变化。UserDetailsService 不再是返回一个写死的用户而是到数据库表里查用户记录。为了支撑这个变化需要建用户表、需要实现按用户名查询的方法。第二层是密码存储与校验方式发生变化。内存用户阶段可以偷懒用{noop}表示不加密但数据库方案一定要升级为 BCrypt 这类不可逆哈希因为数据库一旦泄露明文密码等于批量泄露。第三层是认证链路发生变化。之前 InMemoryUserDetailsManager 自己内部就处理完了切到数据库之后Spring Security 的 DaoAuthenticationProvider 会调用我们实现的 UserDetailsService 加载用户再用 PasswordEncoder 校验密码链路比以前长但每个环节都可控。这里可以列个简单的演进对比方案用户存储密码形式可注册生产可用内存用户内存Map明文或Noop不支持否数据库MD5数据库表MD5散列支持勉强但不推荐数据库BCrypt数据库表随机盐慢哈希支持推荐演进到数据库认证之后下一步就是密码加密方案的选型。这两件事是绑在一起的只改数据库不换加密等于换汤不换药。1.3 整体架构与项目准备本文示例采用 Spring Boot 3 作为基础框架Spring Security 6 作为安全框架数据访问用 Spring JDBC 的 JdbcTemplate。之所以不引入 MyBatis 或 JPA是为了把注意力集中在 Security 本身少一层 ORM 的干扰。实际项目中你用 MyBatis-Plus 还是 Spring Data JPA 都不影响这套认证逻辑的落地UserDetailsService 里的查询换成任何 ORM 写法都行。项目依赖只需要四个核心模块spring-boot-starter-web提供 Web 容器和接口能力。spring-boot-starter-security提供安全认证和授权能力。spring-boot-starter-jdbc提供数据库访问。mysql-connector-j或对应数据库驱动连接 MySQL。至于表结构建一张sys_user表是最基本的要求字段包括主键、用户名、密码哈希、昵称、状态、创建时间等。2. 密码加密不能只做到“看不清”2.1 明文密码到底有多危险很多人有个错觉觉得密码存在数据库里只要做不了 SQL 查询别人就看不到。但数据库泄露从来不是“能不能看到”的问题而是“多长时间能看到”的问题。明文密码一旦落入攻击者手里不仅是当前系统失守用户如果在其他平台用了同一个密码连锁反应会波及邮箱、支付、社交账号。这个叫撞库是黑色产业里最常见的一条路径。就算不泄露明文密码在内部也有风险。运维同事能查到所有人的密码离职员工可能留着数据库备份第三方排查问题时顺手看到。安全领域有个原则叫“最小知识原则”意思是每个人只应该知道完成工作所必需的信息。密码这个东西连用户自己都不该被提醒更不该被系统保存成可读的原始字符串。2.2 MD5 为什么被安全社区“嫌弃”有人会说那我把密码用 MD5 加密一下再存数据库不就行了吗MD5 确实不是明文但它远远不够。MD5 的问题有三个。第一MD5 是一种快速哈希算法计算速度极快攻击者可以用 GPU 在短时间内跑海量组合配合字典和规则碰撞出原始密码。第二MD5 固定盐或者不加盐时相同密码会得到相同哈希攻击者可以预先用彩虹表建立哈希到明文的映射查表就能反推出密码。第三MD5 本身被发现了碰撞漏洞虽然对密码存储场景的影响没有前面两个那么直接但业界早已不推荐在密码领域继续使用。给 MD5 加盐能解决彩虹表问题但只要是普遍使用的快哈希暴力枚举成本依然很低。密码加密的正确思路不是“算得快”而是“算得慢”。慢到攻击者枚举一次要耗费巨大算力同时又不能慢到用户登录体验不可接受。2.3 BCrypt 到底做了什么BCrypt 是目前 Spring Security 官方推荐的密码哈希方案它之所以能站稳脚跟靠的是三个设计。第一它是基于 Blowfish 加密算法的自适应哈希函数输出结果中会带上随机盐和强度因子。这意味着即使两个人密码完全相同每次算出来的哈希字符串也不一样彩虹表直接失效。第二它的计算强度是可调的。默认强度是 10表示要进行 2 的 10 次方轮迭代可以根据服务器性能调高。第三它的输出格式自带信息比如$2a$10$...这段字符串里2a表示算法版本10表示强度后面的 22 个字符是盐再往后才是真正的哈希值。Spring Security 在验证时只需要读取哈希字符串本身就能知道用的是什么参数所以同一个系统里允许存在不同强度、不同算法的密码这在老系统迁移时特别有用。2.4 PasswordEncoder 家族与选择建议Spring Security 5 之后官方默认的 PasswordEncoder 是DelegatingPasswordEncoder它不是某个具体的算法而是一个“代理”通过前缀来识别使用哪种算法。比如{bcrypt}前缀表示 BCrypt{noop}表示不加密{MD5}表示 MD5。你可能会问为什么搞这么复杂直接全部换成 BCrypt 不就行了关键在升级场景。一个老系统里可能并存着不同时期注册的密码有些是 MD5有些是明文如果直接一刀切改成 BCrypt所有老用户全部登录失败。DelegatingPasswordEncoder可以在验证时兼容多种格式同时又支持把新密码统一存为 BCrypt 格式实现平滑过度。所以我的建议很明确新项目直接用 BCrypt不要犹豫。老项目要改造用DelegatingPasswordEncoder兜底逐步把老哈希迁移成 BCrypt。3. 从内存用户到数据库用户的核心实操3.1 数据库表设计与建表 SQL认证表不需要设计得多复杂核心字段围绕“用户唯一标识”“密码哈希”“账号状态”来定CREATE TABLE sys_user ( id BIGINT AUTO_INCREMENT PRIMARY KEY, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(100) NOT NULL, nickname VARCHAR(50) DEFAULT , status TINYINT DEFAULT 1, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP );这里有几个字段的设计讲究。username必须加唯一约束这是认证的前提重复用户名会导致 UserDetailsService 不知道该返回哪个用户。password字段建议长度不小于 60 个字符因为 BCrypt 哈希本身固定是 60 个字符加上前缀{bcrypt}后会更长如果设计成 32 个字符的字段存进去会被截断导致所有密码校验失败。status字段用来做账号禁用、冻结等状态控制返回的 UserDetails 里可以通过布尔值映射出来。3.2 实现 UserDetailsService 并加载数据库用户UserDetailsService 在 Spring Security 中扮演的角色就是“根据用户名查用户”。它唯一需要实现的方法就是loadUserByUsername(String username)。Service public class DatabaseUserDetailsService implements UserDetailsService { private final JdbcTemplate jdbcTemplate; public DatabaseUserDetailsService(JdbcTemplate jdbcTemplate) { this.jdbcTemplate jdbcTemplate; } Override public UserDetails loadUserByUsername(String username) throws UsernameNotFoundException { String sql SELECT username, password, nickname, status FROM sys_user WHERE username ?; ListMapString, Object rows jdbcTemplate.queryForList(sql, username); if (rows.isEmpty()) { throw new UsernameNotFoundException(用户不存在: username); } MapString, Object row rows.get(0); String password (String) row.get(password); boolean enabled Integer.valueOf(1).equals(row.get(status)); return User.withUsername(username) .password(password) .roles(USER) .disabled(!enabled) .build(); } }注意这里查询用了?占位符而不是字符串拼接就是为了从一开始就防住 SQL 注入。很多人觉得 SQL 注入是老生常谈但在真实项目里由于赶工或不注意拼接 SQL 的情况依然不少。Spring Security 的认证过程会把你传入的用户名直接交给 UserDetailsService 处理如果用户名拼进 SQL攻击者就能在登录接口上做文章。这里角色我先统一写死为USER实际系统一般会引入角色表和用户角色关联表但这和认证链路无关不展开也能跑通。3.3 配置 SecurityConfig 与密码编码器接下来是把自定义的 UserDetailsService 接入 Spring Security 的配置。以下是一个最简的可运行配置Configuration EnableWebSecurity public class SecurityConfig { private final DatabaseUserDetailsService userDetailsService; public SecurityConfig(DatabaseUserDetailsService userDetailsService) { this.userDetailsService userDetailsService; } Bean public PasswordEncoder passwordEncoder() { return new BCryptPasswordEncoder(); } Bean public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception { http .authorizeHttpRequests(auth - auth .requestMatchers(/login, /register).permitAll() .anyRequest().authenticated() ) .formLogin(form - form .loginPage(/login) .permitAll() ) .logout(logout - logout.permitAll()) .userDetailsService(userDetailsService) .csrf(csrf - csrf.disable()); return http.build(); } }有两点要注意一下。一是userDetailsService(...)这个方法。虽然 Spring Security 会自动从容器里找 UserDetailsService但为了明确最好显式设置。不设置的风险是当容器里有多个 UserDetailsService 或存在自定义认证逻辑时容易出现“到底用哪个”的歧义。二是csrf.disable()。生产环境拆不拆要看你的实际交互方式。如果是前后端分离、走 Token 认证CSRF 防护可以关掉如果是传统表单登录、依赖 Session打开 CSRF 更稳妥代价是登录表单里要带上 token。示例中先关掉方便调试接口。3.4 注册接口密码从明文变成 BCrypt 哈希数据库切换不能只改登录还要考虑新用户怎么进去。如果注册接口把密码明文存了登录再安全也白搭。下面是一个简单的注册接口RestController public class AuthController { private final JdbcTemplate jdbcTemplate; private final PasswordEncoder passwordEncoder; public AuthController(JdbcTemplate jdbcTemplate, PasswordEncoder passwordEncoder) { this.jdbcTemplate jdbcTemplate; this.passwordEncoder passwordEncoder; } PostMapping(/register) public String register(RequestBody RegisterRequest request) { String encodedPassword passwordEncoder.encode(request.password()); jdbcTemplate.update( INSERT INTO sys_user (username, password, nickname) VALUES (?, ?, ?), request.username(), encodedPassword, request.nickname() ); return 注册成功; } }密码在这里先通过PasswordEncoder.encode()转换成 BCrypt 字符串再写进数据库。这一步是目前为止最重要的一行代码。注册时如果不做加密后续所有安全设计都存在最脆弱的环节。可以实际打印一下 encode 出来的值形如$2a$10$CwT6TZ...每次执行结果都不一样但都能通过matches()方法验证成功。这就是 BCrypt 的随机盐在起作用。3.5 演示登录验证与数据库里的密码形态启动项目访问/login用注册好的账号登录。Spring Security 会自动读取表单中的 username 和 password交给 DaoAuthenticationProviderprovider 再调用我们实现的 DatabaseUserDetailsService 加载数据库用户最后用 PasswordEncoder 对输入密码和数据库中的 BCrypt 哈希做比对。如果一切正常登录成功后会跳到默认的/路径。此时打开数据库看一下sys_user表password 字段存储的绝对不是明文而是类似$2a$10$WnQ...的长字符串。到这里从内存用户到数据库用户的迁移就算完成了。4. 登录认证的完整流程与关键机制解析4.1 一次登录请求背后的完整链路很多初学者配置完之后能跑但说不清一次登录请求内部发生了什么。我把它拆成下面这条链路方便理解浏览器向/login提交用户名和密码请求先打到UsernamePasswordAuthenticationFilter。这个过滤器负责把请求参数封装成一个UsernamePasswordAuthenticationToken同时把未认证状态标记上去。接着这个 token 被交给AuthenticationManager在 Spring Security 中默认实现是ProviderManager。ProviderManager会遍历所有已注册的AuthenticationProvider找到能处理用户名密码认证的DaoAuthenticationProvider。DaoAuthenticationProvider先从UserDetailsService中加载用户数据加载不到就抛UsernameNotFoundException加载到了就把表单里的明文密码和数据库中的哈希交给PasswordEncoder.matches()比对一致则返回一个完整的认证对象不一致则抛BadCredentialsException。认证成功之后认证对象会存进 SecurityContext后续请求通过过滤器链就可以直接读取当前用户信息。这条链路拆开看并不复杂每个环节都有清晰的职责和扩展点。你想加验证码、加手机号登录、加多因素认证本质上就是在链路上的某个位置做自定义扩展。4.2 认证成功与失败从白标页面到 JSON 响应默认的表单登录在成功或失败之后是实现类自动重定向。搭建项目没问题但前后端分离时前端更期望收到 JSON 结构。在 Security 6 中可以这样定制.formLogin(form - form .loginProcessingUrl(/login) .successHandler((request, response, authentication) - { response.setContentType(application/json;charsetutf-8); response.getWriter().write({\code\:0,\message\:\登录成功\}); }) .failureHandler((request, response, exception) - { response.setContentType(application/json;charsetutf-8); response.setStatus(HttpServletResponse.SC_UNAUTHORIZED); response.getWriter().write({\code\:401,\message\:\用户名或密码错误\}); }) )这里有个容易被忽略的小坑一旦自定义了失败处理器异常类型就没有被框架吃掉你必须自己决定返回什么。如果是用户不存在、密码错误、账号禁用返回给前端的提示应该统一且模糊不要直接说“用户不存在”否则攻击者可以通过提示不断尝试用户名是否存在。推荐统一返回“用户名或密码错误”。4.3 会话管理与“记住我”表单登录默认会把认证信息放在 Session 里浏览器靠 Cookie 里的 Session ID 维持登录状态。这是经典方案也算稳定。需要注意的是一次性会话和并发登录控制.sessionManagement(session - session .maximumSessions(1) .maxSessionsPreventsLogin(true) )这个配置的含义是同一个用户只允许一个会话存在当新的会话建立时旧会话会被踢出或阻止新登录具体取决于maxSessionsPreventsLogin的值。这个功能在会员类系统里几乎是标配不然一个账号可以无限多地登录异常行为很难追踪。“记住我”功能原理是登录成功后生成一个持久化 Token存在数据库persistent_logins表里下次用户带这个 Token 回来就可以自动登录。这个功能不是安全重点但体验提升明显感兴趣可以单独研究。4.4 扩展方向前后端分离与无状态认证一旦做完数据库认证很多人下一步就会问Token 怎么做JWT 怎么集成Spring Security 本身不绑定会话或 JWT它给出的是一套认证机制你可以通过SecurityContextHolder来获取当前认证信息也可以在过滤器链上提前解析 Token 并手动把认证信息塞进去。我的建议是不要把 JWT 当成第一个优先方向先彻底搞懂 Session 认证和过滤器链的原理再去写 JWT 过滤器会顺手很多。原理通了JWT 只是换了一个“把认证信息放哪里”的载体。5. 常见问题与排查技巧5.1 密码明明正确就是登录失败这个现象出现频率极高。我用一个表格把常见原因和处理方法列出来现象大概率原因解决方案登录页面提示用户名或密码错误PasswordEncoder 类型不一致检查配置类里是否注册了 BCryptPasswordEncoder且没被覆盖数据库里密码有{noop}前缀但代码用 BCryptDelegatingPasswordEncoder 前缀未匹配统一统一前缀或用{bcrypt}存 BCrypt 哈希数据库密码字段长度不够BCrypt 哈希被截断修改字段长度到 80 以上重新存储密码新注册用户能登录老用户不能老用户密码还是明文或 MD5写迁移任务批量将老密码升级为 BCrypt有一种情况特别坑在某个类里手动new BCryptPasswordEncoder()而 SecurityConfig 里注入了另一个 PasswordEncoder导致注册时加密和登录时校验用的根本不是同一个实例。推荐整个工程都从容器里拿 PasswordEncoder不要到处 new。5.2 登录接口返回 403 而不是 401403 通常是权限不足401 是未认证。初学者经常遇到“明明登录逻辑没问题就是返回 403”的情况。常见原因有两个。第一是.requestMatchers(/login)没有放开。如果登录页本身也被拦截了请求还没走到认证过滤器就直接被拒绝。要确认 permitAll 的范围覆盖登录接口、静态资源和注册接口。第二是 CSRF 防护生效了。如果表单没有带_csrftokenSpring Security 会直接拒绝请求表现为 403。测试阶段可以先关掉 CSRF上线前再评估是否需要开启。5.3 循环依赖UserDetailsService 和 PasswordEncoder 互相引用有一种设计隐患是UserDetailsService 构造函数里注入 PasswordEncoder而 PasswordEncoder 又被放在 SecurityConfig 里SecurityConfig 又依赖 UserDetailsService。逻辑上绕了一圈容易引发循环依赖。建议把包含业务逻辑的 UserDetailsService 和纯配置的 PasswordEncoder 拆分清楚。比如 PasswordEncoder 单独放在一个Configuration类里UserDetailsService 只依赖 JdbcTemplate 或 Mapper不要让它反过来依赖安全配置类。这样既清晰也避免 Spring 启动时的循环依赖报错。5.4 老系统明文密码的迁移方案接手一个存量系统时你会发现数据库里既有明文、又有 MD5还有部分 BCrypt这是历史“成果”。直接一步切换到 BCrypt 会让大量用户登录失败怎么办最稳妥的做法是分两步走。第一步让系统在“验证”阶段兼容多种算法明文直接比较MD5 用 MD5 处理后比较BCrypt 用 matches。验证通过之后在“迁移”阶段把明文或 MD5 转换为 BCrypt。可以在每次成功登录时判断当前密码的编码方式如果不是{bcrypt}前缀就重新encode用户提交的明文密码并更新数据库。这样不用打扰用户迁移是在日常登录中悄悄完成的。5.5 几个提升体验的小细节第一个密码策略不能完全没有。至少要限制最小长度和复杂度BCrypt 只负责存储安全不负责用户密码强度。用 Spring Security 的PasswordValidator或自定义校验都可以。第二个登录接口要做限流和防暴力破解。BCrypt 本身很慢能够拖慢攻击速度但数据库查询和连接资源仍然会消耗。最简单的方案是在登录失败接口上做 IP 维度或用户名维度的失败次数限制连续失败多次就锁定一段时间。第三个不要再把敏感信息打印到日志里。登录失败时Spring Security 抛出的异常堆栈可能包含一些内部细节如果用全局异常处理器统一捕获记日志时注意不要把用户输入的明文密码打出来。写在最后的一些实际体会做这个改造的过程中我最大的体会是Spring Security 的难点不是配置怎么写而是搞清楚每个默认行为背后的设计意图。比如{noop}看起来只是给初学者用的但它其实揭示了 PasswordEncoder 的扩展机制理解了它就理解了为什么老系统可以平滑升级。再比如 BCrypt 的随机盐看似是“多此一举”实际是为了彻底瓦解彩虹表攻击。这些设计不是凭空来的每一个都是针对真实威胁的应对方案。如果让我给刚上手的人一个建议我不会让他先去背配置项而是让他把代码里所有密码相关的位置全部过一遍确保每一处写入数据库的密码都经过PasswordEncoder.encode()每一处校验都走matches()。这个底线守住Spring Security 的其他功能可以慢慢加安全问题不会在第一步就漏风。最后分享一个小技巧如果你只是想在本地快速联调又不想造数据库数据可以临时把内存用户的密码前缀保留为{noop}方便抓包观察登录流程。但凡是提交到远程分支、部署到公共环境务必换成 BCrypt走正规的数据库认证。用一句话总结我自己的态度登录功能可以很简单但密码的存放方式永远不能图省事。
