Spring Security 5中DigestAuthenticationFilter如何避免使用已弃用密码编码器？

这确实是Spring Security里Digest认证的一个头疼点——默认配置下因为需要明文密码来生成验证摘要，不得不启用早已被弃用的NoOpPasswordEncoder。不过其实有两种靠谱的方案能绕开这个限制，帮你兼顾Digest认证需求和安全性：

方案1：存储预计算的Digest哈希值，自定义PasswordEncoder #

先理清楚Digest认证的核心逻辑：客户端会用「用户名+密码+realm+随机参数」生成一个摘要发送给服务器，服务器需要用同样的参数（包括用户密码）生成对比摘要。但这里的密码不一定非得是明文——如果我们提前把MD5(用户名:realm:密码)这个中间哈希值存在数据库里，服务器就能直接用这个值完成后续的验证，完全不需要明文密码。

具体操作步骤：

1. 自定义PasswordEncoder：因为我们存的已经是Digest需要的预计算哈希，所以这个编码器不需要做加密操作，只需要让认证流程正常推进就行：

public class DigestPasswordEncoder implements PasswordEncoder {
    @Override
    public String encode(CharSequence rawPassword) {
        // 注意：我们不需要在这里编码，因为用户密码已经预计算成MD5(用户名:realm:密码)存在数据库了
        throw new UnsupportedOperationException("直接存储预计算的MD5哈希，无需编码");
    }

    @Override
    public boolean matches(CharSequence rawPassword, String encodedPassword) {
        // 实际的摘要匹配逻辑由DigestAuthenticationFilter完成，这里只需返回true让流程继续
        return true;
    }
}

2. 配置Digest认证组件：确保DigestAuthenticationEntryPoint的realm和你预计算哈希时用的realm完全一致，同时把自定义的编码器传给DigestAuthenticationFilter：

@Configuration
@EnableWebSecurity
public class SecurityConfig {

    private final UserDetailsService userDetailsService;

    public SecurityConfig(UserDetailsService userDetailsService) {
        this.userDetailsService = userDetailsService;
    }

    @Bean
    public DigestAuthenticationEntryPoint digestEntryPoint() {
        DigestAuthenticationEntryPoint entryPoint = new DigestAuthenticationEntryPoint();
        entryPoint.setRealmName("YourAppRealm"); // 必须和预计算哈希时用的realm一致！
        entryPoint.setKey("your-unique-secret-key"); // 自定义一个随机密钥，用于生成nonce
        return entryPoint;
    }

    @Bean
    public DigestAuthenticationFilter digestFilter() {
        DigestAuthenticationFilter filter = new DigestAuthenticationFilter();
        filter.setUserDetailsService(userDetailsService);
        filter.setAuthenticationEntryPoint(digestEntryPoint());
        filter.setPasswordEncoder(new DigestPasswordEncoder()); // 用自定义编码器替代NoOp
        return filter;
    }

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http
            .addFilterBefore(digestFilter(), BasicAuthenticationFilter.class)
            .authorizeRequests()
            .anyRequest().authenticated();
    }
}

3. 用户数据准备：创建用户时，别存明文或BCrypt加密后的密码，而是预计算MD5(用户名:realm:密码)的值存在数据库里。比如用户名是user，realm是YourAppRealm，密码是password，就计算MD5(user:YourAppRealm:password)得到哈希值存储。

方案2：动态获取明文密码（仅适用于可逆加密场景，不推荐） #

如果你的系统必须存储可逆加密的密码（比如AES加密），可以实现UserDetailsPasswordService来解密密码供Digest认证使用。但注意：这种方案安全性极低，因为解密密码会带来泄露风险，而且如果用的是BCrypt、Argon2这类不可逆的强加密算法，这个方案根本行不通。所以除非万不得已，别用这个思路。

关键提醒 #

• Digest认证本身的安全性不如HTTPS+Basic认证，也不如OAuth2这类现代认证方式，如果条件允许，优先考虑替换成更安全的方案。
• 如果你用的是不可逆的密码加密算法（比如BCrypt），那Digest认证天生不适合你的系统，因为无法从加密后的密码还原出Digest需要的原始材料，强行用只会引入安全隐患。

内容的提问来源于stack exchange，提问作者Pavel Kolmykov