标签:注意 == 根据 中间 委托 LTP 这不 config turn
1. 前言上一文(https://www.felord.cn)我们对Spring Security中的重要用户信息主体UserDetails
进行了探讨。中间例子我们使用了明文密码,规则是通过对密码明文添加{noop}
前缀。那么本节将对 Spring Security 中的密码编码进行一些探讨。
首先md5
不是加密算法,是哈希摘要。以前通常使用其作为密码哈希来保护密码。由于彩虹表的出现,md5
和sha1
之类的摘要算法都已经不安全了。如果有不相信的同学 可以到一些解密网站 如 cmd5 网站尝试解密 你会发现 md5
和 sha1
是真的非常容易被破解。
上一文(https://www.felord.cn)我们提到了`InMemoryUserDetailsManager初始化Bean 需要传输一个
ObjectProvider<PasswordEncoder>参数。这里的
PasswordEncoder`就是我们对密码进行编码的工具接口。该接口只有两个功能:一个是匹配验证。另一个是密码编码。
上图就是Spring Security 提供的org.springframework.security.crypto.password.PasswordEncoder
一些实现,有的已经过时。其中我们注意到一个叫委托密码编码器的实现 。
什么是委托(Delegate)?就是甲方交给乙方的活。乙方呢手里又很多的渠道,但是乙方光想赚差价又不想干活。所以乙方根据一些规则又把活委托给了别人,让别人来干。这里的乙方就是DelegatingPasswordEncoder
。该类维护了以下清单:
final String idForEncode
通过id来匹配编码器,该id不能是{}
包括的。DelegatingPasswordEncoder
初始化传入,用来提供默认的密码编码器。final PasswordEncoder passwordEncoderForEncode
通过上面idForEncode
所匹配到的PasswordEncoder
用来对密码进行编码。final Map<String, PasswordEncoder> idToPasswordEncoder
用来维护多个idForEncode
与具体PasswordEncoder
的映射关系。DelegatingPasswordEncoder
初始化时装载进去,会在初始化时进行一些规则校验。PasswordEncoder defaultPasswordEncoderForMatches = new UnmappedIdPasswordEncoder()
默认的密码匹配器,上面的Map
中都不存在就用它来执行matches
方法进行匹配验证。这是一个内部类实现。DelegatingPasswordEncoder
编码方法:
@Override
public String encode(CharSequence rawPassword) {
return PREFIX + this.idForEncode + SUFFIX + this.passwordEncoderForEncode.encode(rawPassword);
}
从上面源码可以看出来通过DelegatingPasswordEncoder
编码后的密码是遵循一定的规则的,遵循{idForEncode}encodePassword
。也就是前缀{}
包含了编码的方式再拼接上该方式编码后的密码串。
DelegatingPasswordEncoder
密码匹配方法:
@Override
public boolean matches(CharSequence rawPassword, String prefixEncodedPassword) {
if (rawPassword == null && prefixEncodedPassword == null) {
return true;
}
String id = extractId(prefixEncodedPassword);
PasswordEncoder delegate = this.idToPasswordEncoder.get(id);
if (delegate == null) {
return this.defaultPasswordEncoderForMatches
.matches(rawPassword, prefixEncodedPassword);
}
String encodedPassword = extractEncodedPassword(prefixEncodedPassword);
return delegate.matches(rawPassword, encodedPassword);
}
密码匹配通过传入原始密码和遵循{idForEncode}encodePassword
规则的密码编码串。通过获取编码方式id (idForEncode
) 来从 DelegatingPasswordEncoder
中的映射集合idToPasswordEncoder
中获取具体的PasswordEncoder
进行匹配校验。找不到就使用UnmappedIdPasswordEncoder
。
这就是 DelegatingPasswordEncoder
的工作流程。那么DelegatingPasswordEncoder
在哪里实例化呢?
从名字上就看得出来这是个工厂啊,专门制造 PasswordEncoder
。而且还是个静态工厂只提供了初始化DelegatingPasswordEncoder
的方法:
@SuppressWarnings("deprecation")
public static PasswordEncoder createDelegatingPasswordEncoder() {
String encodingId = "bcrypt";
Map<String, PasswordEncoder> encoders = new HashMap<>();
encoders.put(encodingId, new BCryptPasswordEncoder());
encoders.put("ldap", new org.springframework.security.crypto.password.LdapShaPasswordEncoder());
encoders.put("MD4", new org.springframework.security.crypto.password.Md4PasswordEncoder());
encoders.put("MD5", new org.springframework.security.crypto.password.MessageDigestPasswordEncoder("MD5"));
encoders.put("noop", org.springframework.security.crypto.password.NoOpPasswordEncoder.getInstance());
encoders.put("pbkdf2", new Pbkdf2PasswordEncoder());
encoders.put("scrypt", new SCryptPasswordEncoder());
encoders.put("SHA-1", new org.springframework.security.crypto.password.MessageDigestPasswordEncoder("SHA-1"));
encoders.put("SHA-256", new org.springframework.security.crypto.password.MessageDigestPasswordEncoder("SHA-256"));
encoders.put("sha256", new org.springframework.security.crypto.password.StandardPasswordEncoder());
return new DelegatingPasswordEncoder(encodingId, encoders);
}
从上面可以非常具体地看出来DelegatingPasswordEncoder
提供的密码编码方式。默认采用了bcrypt 进行编码。我们可终于明白了为什么上一文中我们使用 {noop12345}
能和我们前台输入的12345
匹配上。这么搞有什么好处呢?这可以实现一个场景,如果有一天我们对密码编码规则进行替换或者轮转。现有的用户不会受到影响。 那么Spring Security 是如何配置密码编码器PasswordEncoder
呢?
我们在Spring Security配置适配器WebSecurityConfigurerAdapter
(该类我以后的文章会仔细分析 可通过https://felord.cn
来及时获取相关信息)找到了引用PasswordEncoderFactories
的地方,一个内部 PasswordEncoder
实现 LazyPasswordEncoder
。从源码上看该类是懒加载的只有用到了才去实例化。在该类的内部方法中发现了 PasswordEncoder
的规则。
// 获取最终干活的PasswordEncoder
private PasswordEncoder getPasswordEncoder() {
if (this.passwordEncoder != null) {
return this.passwordEncoder;
}
PasswordEncoder passwordEncoder = getBeanOrNull(PasswordEncoder.class);
if (passwordEncoder == null) {
passwordEncoder = PasswordEncoderFactories.createDelegatingPasswordEncoder();
}
this.passwordEncoder = passwordEncoder;
return passwordEncoder;
}
// 从Spring IoC容器中获取Bean 有可能获取不到
private <T> T getBeanOrNull(Class<T> type) {
try {
return this.applicationContext.getBean(type);
} catch(NoSuchBeanDefinitionException notFound) {
return null;
}
}
上面的两个方法总结:如果能从从Spring IoC容器中获取PasswordEncoder
的Bean就用该Bean作为编码器,没有就使用DelegatingPasswordEncoder
。默认是 bcrypt
方式。文中多次提到该算法。而且还是Spring Security默认的。那么它到底是什么呢?
这里简单提一下bcrypt
, bcrypt
使用的是布鲁斯·施内尔在1993年发布的 Blowfish
加密算法。bcrypt
算法将salt
随机并混入最终加密后的密码,验证时也无需单独提供之前的salt
,从而无需单独处理salt
问题。加密后的格式一般为:
$2a$10$/bTVvqqlH9UiE0ZJZ7N2Me3RIgUCdgMheyTgV0B4cMCSokPa.6oCa
其中:$
是分割符,无意义;2a
是bcrypt
加密版本号;10
是cost
的值;而后的前22
位是salt
值;再然后的字符串就是密码的密文了。
bcrypt
有个特点就是非常慢。这大大提高了使用彩虹表进行破解的难度。也就是说该类型的密码暗文拥有让破解者无法忍受的时间成本。同时对于开发者来说也需要注意该时长是否能超出系统忍受范围内。通常是MD5
的数千倍。bcrypt
编码,密码暗文都是不一样的。 也就是说你有两个网站如果都使用了bcrypt
它们的暗文是不一样的,这不会因为一个网站泄露密码暗文而使另一个网站也泄露密码暗文。所以从bcrypt
的特点上来看,其安全强度还是非常有保证的。
今天我们对Spring Security中的密码编码进行分析。发现了默认情况下使用bcrypt
进行编码。而密码验证匹配则通过密码暗文前缀中的加密方式id控制。你也可以向Spring IoC容器注入一个PasswordEncoder
类型的Bean 来达到自定义的目的。我们还对bcrypt
算法进行一些简单了解,对其特点进行了总结。后面我们会Spring Security进行进一步学习。关于上一篇文章的demo我也已经替换成了数据库管理用户。
标签:注意 == 根据 中间 委托 LTP 这不 config turn
原文地址:https://blog.51cto.com/14901317/2529092