默认情况下（从 Spring Security 3.1 开始），ProviderManager 将尝试清除由成功身份验证请求返回的身份验证对象中的任何敏感凭证信息。这样可以防止口令信息被保留的时间比必要的时间长。

例如，在使用用户对象缓存时，这可能会导致在无状态应用程序中提高性能。如果 Authentication 包含对缓存中的对象（例如 UserDetails 实例）的引用，并且删除了凭证，那么就不能再根据缓存的值进行身份验证。如果使用缓存，则需要考虑这一点。一个明显的解决方案是首先在缓存实现中或在创建返回的 Authentication 对象的 AuthenticationProvider 中复制对象。或者，你可以禁用 ProviderManager 上的 eraseCredentialsAfterAuthentication 属性。有关的更多详细信息，请参阅 JavaDoc。

Spring Security 实现的最简单的 AuthenticationProvider 是 DaoAuthenticationProvider，也是框架最早支持的之一。它利用 UserDetailsService（作为 DAO）来查找用户名、密码和 GrantedAuthority。它通过比较 UsernamePasswordAuthenticationToken 中提交的密码与 UserDetailsService 加载的密码来验证用户。配置提供程序非常简单：

<bean id="daoAuthenticationProvider"
	class="org.springframework.security.authentication.dao.DaoAuthenticationProvider">
<property name="userDetailsService" ref="inMemoryDaoImpl"/>
<property name="passwordEncoder" ref="passwordEncoder"/>
</bean>

PasswordEncoder 是可选的。PasswordEncoder 提供对 UserDetails 对象中呈现的密码的编码和解码，该对象从配置的 UserDetailsService 返回。这将在下面更详细地讨论。

很容易使用创建自定义 UserDetailsService 实现，它从选择的持久性引擎中提取信息，但许多应用程序不需要这样的复杂性。如果你正在构建一个原型应用程序，或者刚开始集成 Spring Security，当你不想花费时间配置数据库或编写 UserDetailsService 实现时，这一点尤其适用。对于这种情况，一个简单的选择是使用安全 命名空间中的 user-service 元素：

<user-service id="userDetailsService">
<!-- Password is prefixed with {noop} to indicate to DelegatingPasswordEncoder that
NoOpPasswordEncoder should be used. This is not safe for production, but makes reading
in samples easier. Normally passwords should be hashed using BCrypt -->
<user name="jimi" password="{noop}jimispassword" authorities="ROLE_USER, ROLE_ADMIN" />
<user name="bob" password="{noop}bobspassword" authorities="ROLE_USER" />
</user-service>

这也支持使用外部属性文件：

<user-service id="userDetailsService" properties="users.properties"/>

属性文件应该包含表单中的条目

username=password,grantedAuthority[,grantedAuthority][,enabled|disabled]

例如

jimi=jimispassword,ROLE_USER,ROLE_ADMIN,enabled
bob=bobspassword,ROLE_USER,enabled

Spring Security 还包括可以从 JDBC 数据源获得身份验证信息的 UserDetailsService。使用内部 Spring JDBC，因此它避免了仅存储用户细节的全功能对象关系映射器（ORM）的复杂性。如果你的应用程序确实使用 ORM 工具，那么你可能更喜欢编写自定义 UserDetailsService 来重用你可能已经创建的映射文件。回到 JdbcDaoImpl，示例配置如下所示：

<bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource">
<property name="driverClassName" value="org.hsqldb.jdbcDriver"/>
<property name="url" value="jdbc:hsqldb:hsql://localhost:9001"/>
<property name="username" value="sa"/>
<property name="password" value=""/>
</bean>

<bean id="userDetailsService"
	class="org.springframework.security.core.userdetails.jdbc.JdbcDaoImpl">
<property name="dataSource" ref="dataSource"/>
</bean>

可以通过修改上面所示的 DriverManagerDataSource 来使用不同的关系数据库管理系统。还可以使用从 JNDI 获得的全局数据源，也可以使用任何其它 Spring 配置。

多年来，存储密码的标准机制已经发展。开始时密码以明文形式存储。密码被认为是安全的，因为数据存储的密码保存在所需的凭证中以访问密码。然而，恶意用户能够找到使用 SQL 注入等攻击获取用户名和密码的大量数据转储的方法。随着越来越多的用户凭证成为公共安全问题，意识到我们需要做更多的工作来保护用户密码。

然后鼓励开发人员在通过单向散列（例如 SHA-256）运行密码后存储密码。当用户试图进行身份验证时，将哈希密码与它们键入的密码的哈希值进行比较。这意味着系统只需要存储口令的单向散列。如果发生了攻破，则只有密码的单向散列被暴露。由于散列是单向的，而且在计算上很难猜测给定散列的密码，因此不值得努力找出系统中的每个密码。为了击败这个新系统，恶意用户决定创建被称为彩虹表的查找表。不是每次都做猜测每一个密码的工作，而是计算一次密码并将其存储在查找表中。

为了减少彩虹表的有效性，鼓励开发人员使用加盐密码。代替只使用密码作为哈希函数的输入，将为每个用户的密码生成随机字节（称为加盐）。通过生成的哈希函数运行盐和用户密码。盐将与用户密码一起存储在明文中。然后，当用户试图进行身份验证时，将散列密码与存储的盐的散列和他们键入的密码进行比较。独特的加盐意味着彩虹表不再有效，因为哈希对于每个加盐和密码组合都不同。

在现代，我们认识到密码散列（如 SHA-256）不再安全。原因是，用现代硬件，我们可以一秒钟执行数十亿的散列计算。这意味着我们可以轻松地破解每个密码。

现在鼓励开发人员利用自适应单向函数来存储密码。使用自适应单向函数验证密码是有意的资源（即 CPU、内存等）密集的。一个自适应单向函数允许配置一个工作因子，它可以随着硬件变得更好而增长。建议将工作因子调整到大约1秒以验证系统上的密码。这种折衷是让攻击者很难破解密码，但不会花费太大，这会给您自己的系统带来过多的负担。Spring Security 试图为工作因素提供一个良好的起点，但是鼓励用户为自己的系统定制工作因素，因为性能会随着系统而急剧变化。应该使用的自适应单向函数的例子包括 bcrypt、PBKDF2、scrypt 和 Argon2。

由于自适应单向函数故意占用大量资源，因此为每个请求验证用户名和密码将显著降低应用程序的性能。Spring Security（或任何其它库）都无法加速密码验证，因为通过使验证资源密集来获得安全性。鼓励用户将长期凭证（即用户名和密码）交换为短期凭证（即 session、OAuth Token 等）。短期凭证可以快速验证而不损失任何安全性。

在 Spring Security 5.0 之前，默认 PasswordEncoder 是需要纯文本密码的 NoOpPasswordEncoder。基于密码历史部分，你可能希望默认的 PasswordEncoder 现在类似于 BCryptPasswordEncoder。然而，这忽略了三个现实世界的问题：

相反，Spring Security 引入了 DelegatingPasswordEncoder，它通过以下方式解决了所有问题：

你可以很容易地使用 PasswordEncoderFactories 构建一个 DelegatingPasswordEncoder 的实例。

PasswordEncoder passwordEncoder =
    PasswordEncoderFactories.createDelegatingPasswordEncoder();

或者，你可以创建自己的自定义实例。例如：

String idForEncode = "bcrypt";
Map encoders = new HashMap<>();
encoders.put(idForEncode, new BCryptPasswordEncoder());
encoders.put("noop", NoOpPasswordEncoder.getInstance());
encoders.put("pbkdf2", new Pbkdf2PasswordEncoder());
encoders.put("scrypt", new SCryptPasswordEncoder());
encoders.put("sha256", new StandardPasswordEncoder());

PasswordEncoder passwordEncoder =
    new DelegatingPasswordEncoder(idForEncode, encoders);

密码存储格式

密码的一般格式是：

{id}encodedPassword

这样，id 是用于查找应该使用哪个 PasswordEncoder 的标识符，encodedPassword 是所选 PasswordEncoder 的原始编码密码。id 必须位于密码的开头，以 { 开头和 } 结尾。如果找不到 id，id 将为 null。例如，下面可能是使用不同 id 编码的密码列表。所有的原始密码都是 "password"。

{bcrypt}$2a$10$dXJ3SW6G7P50lGmMkkmwe.20cQQubK3.HZWzG3YB1tlRy.fqvM/BG 
{noop}password 
{pbkdf2}5d923b44a6d129f3ddf3e3c8d29412723dcbde72445e8ef6bf3b508fbf17fa4ed4d6b99ca763d8dc 
{scrypt}$e0801$8bWJaSu2IKSn9Z9kM+TPXfOc/9bdYSrN1oD9qfVThWEwdRTnO7re7Ei+fUZRJ68k9lTyuTeUp4of4g24hHnazw==$OAOec05+bXxvuu/1qZ6NUR+xQYvYv7BeL1QxwRpY5Pc=  
{sha256}97cde38028ad898ebc02e690819fa220e88c62e0699403e94fff291cfffaf8410849f27605abcbc0 

	第一个密码将具有 bcrypt 的 PasswordEncoder id 和 $2a$10$dXJ3SW6G7P50lGmMkkmwe.20cQQubK3.HZWzG3YB1tlRy.fqvM/BG 的 encodedPassword。当匹配时，它将委托给 BCryptPasswordEncoder
	第二个密码有 noop 的 PasswordEncoder id 和 password 的 encodedPassword。当匹配时，它将委托给 NoOpPasswordEncoder
	第三个密码将具有 pbkdf2 的 PasswordEncoder id 和 5d923b44a6d129f3ddf3e3c8d29412723dcbde72445e8ef6bf3b508fbf17fa4ed4d6b99ca763d8dc 的 encodedPassword。当匹配时，它将委托给 Pbkdf2PasswordEncoder
	第四个密码将具有 scrypt 的 PasswordEncoder id 和 $e0801$8bWJaSu2IKSn9Z9kM+TPXfOc/9bdYSrN1oD9qfVThWEwdRTnO7re7Ei+fUZRJ68k9lTyuTeUp4of4g24hHnazw==$OAOec05+bXxvuu/1qZ6NUR+xQYvYv7BeL1QxwRpY5Pc= 的 encodedPassword。当匹配时，它将委托给 SCryptPasswordEncoder
	最后的密码将具有 将具有 sha256 的 PasswordEncoder id 和 97cde38028ad898ebc02e690819fa220e88c62e0699403e94fff291cfffaf8410849f27605abcbc0 的 encodedPassword。当匹配时，它将委托给 StandardPasswordEncoder

	Note
	一些用户可能担心存储格式是为潜在的黑客提供的。这不是一个问题，因为密码的存储不依赖于算法是一个秘密。此外，大多数格式很容易让攻击者在没有前缀的情况下计算出来。例如，BCrypt 密码通常以 $2a$ 开始。

{bcrypt}$2a$10$dXJ3SW6G7P50lGmMkkmwe.20cQQubK3.HZWzG3YB1tlRy.fqvM/BG

User user = User.withDefaultPasswordEncoder()
  .username("user")
  .password("password")
  .roles("user")
  .build();
System.out.println(user.getPassword());
// {bcrypt}$2a$10$dXJ3SW6G7P50lGmMkkmwe.20cQQubK3.HZWzG3YB1tlRy.fqvM/BG

UserBuilder users = User.withDefaultPasswordEncoder();
User user = users
  .username("user")
  .password("password")
  .roles("USER")
  .build();
User admin = users
  .username("admin")
  .password("password")
  .roles("USER","ADMIN")
  .build();

故障排除

当存储的一个密码没有 id 时，会发生以下错误，如称为密码存储格式的部分所述。

java.lang.IllegalArgumentException: There is no PasswordEncoder mapped for the id "null"
	at org.springframework.security.crypto.password.DelegatingPasswordEncoder$UnmappedIdPasswordEncoder.matches(DelegatingPasswordEncoder.java:233)
	at org.springframework.security.crypto.password.DelegatingPasswordEncoder.matches(DelegatingPasswordEncoder.java:196)

解决错误的最简单方法是切换到显式地提供密码被编码的 PasswordEncoder。解决此问题的最简单方法是找出当前如何存储密码，并显式地提供正确的 PasswordEncoder。如果你正在从 Spring Security 4.2.x 迁移，则可以通过暴露 NoOpPasswordEncoder bean 来还原先前的行为。例如，如果使用 Java 配置，则可以创建一个看起来像：

	Warning
	恢复到 NoOpPasswordEncoder 并不被认为是安全的。相反，你应该迁移到使用 DelegatingPasswordEncoder 来支持安全密码编码。

@Bean
public static NoOpPasswordEncoder passwordEncoder() {
    return NoOpPasswordEncoder.getInstance();
}

如果使用 XML 配置，则可以用 id passwordEncoder 公开 PasswordEncoder：

<b:bean id="passwordEncoder"
        class="org.springframework.security.crypto.password.NoOpPasswordEncoder" factory-method="getInstance"/>

或者，你可以用正确的 id 将所有密码前缀，并继续使用 DelegatingPasswordEncoder。例如，如果你使用 BCrypt，你将从类似的东西迁移密码：

$2a$10$dXJ3SW6G7P50lGmMkkmwe.20cQQubK3.HZWzG3YB1tlRy.fqvM/BG

到

{bcrypt}$2a$10$dXJ3SW6G7P50lGmMkkmwe.20cQQubK3.HZWzG3YB1tlRy.fqvM/BG

对于映射的完整列表，请参阅 PasswordEncoderFactories 的 JavaDoc。

BCryptPasswordEncoder 实现使用广泛支持的 bcrypt 算法来对密码进行散列。为了使它更能抵抗密码破解，bcrypt 是故意放慢的。像其它的自适应单向函数一样，它应该调整大约1秒来验证系统上的密码。

// Create an encoder with strength 16
BCryptPasswordEncoder encoder = new BCryptPasswordEncoder(16);
String result = encoder.encode("myPassword");
assertTrue(encoder.matches("myPassword", result));

Pbkdf2PasswordEncoder 实现使用 PBKDF2 算法来散列密码。为了使它更能抵抗密码破解，PBKDF2 是一个故意放慢的算法。像其它的自适应单向函数一样，它应该调整大约1秒来验证系统上的密码。当需要 FIPS 认证时，该算法是一个很好的选择。

// Create an encoder with all the defaults
Pbkdf2PasswordEncoder encoder = new Pbkdf2PasswordEncoder();
String result = encoder.encode("myPassword");
assertTrue(encoder.matches("myPassword", result));

SCryptPasswordEncoder 实现使用 scrypt 算法来对密码进行散列。为了战胜自定义硬件上的密码破解，scrypt 是一种故意放慢的算法，它需要大量的内存。像其它的自适应单向函数一样，它应该调整大约1秒来验证系统上的密码。

// Create an encoder with all the defaults
SCryptPasswordEncoder encoder = new SCryptPasswordEncoder();
String result = encoder.encode("myPassword");
assertTrue(encoder.matches("myPassword", result));

还有许多其它的 PasswordEncoder 实现，完全是为了向后兼容而存在的。它们都被贬低以表明它们不再被认为是安全的。但是，由于迁移现有的遗留系统是困难的，所以没有删除它们的计划。