《Spring Security3》第四章第三部分翻译下（密码加salt）（转载）

你是否愿意在密码上添加点salt ？

 

如果安全审计人员检查数据库中编码过的密码，在网站安全方面，他可能还会找到一些令其感到担心的地方。让我们查看一下存储的 admin 和 guest 用户的用户名和密码值：

        

用户名	明文密码	加密密码
admin	admin	7b2e9f54cdff413fcde01f330af6896c3cd7e6cd
guest	guest	2ac15cab107096305d0274cd4eb86c74bb35a4b4

         这看起来很安全——加密后的密码与初始的密码看不出有任何相似性。但是如果我们添加一个新的用户，而他碰巧和 admin 用户拥有同样的密码时，又会怎样呢？

 

用户名	明文密码	加密密码
fakeadmin	admin	7b2e9f54cdff413fcde01f330af6896c3cd7e6cd

         现在，注意 fakeadmin 用户加密过后密码与 admin 用户完全一致。所以一个黑客如果能够读取到数据库中加密的密码，就能够对已知的密码加密结果和 admin 账号未知的密码进行对比，并发现它们是一样的。如果黑客能够使用自动化的工具来进行分析，他能够在几个小时内破坏管理员的账号。

【鉴于作者本人使用了一个数据库，它里面的密码使用了完全一致的加密方式，我和工程师团队决定进行一个小的实验并查看明文 password 的 SHA-1 加密值。当我们得到 password 的加密形式并进行数据库查询来查看有多少人使用这个相当不安全的密码。让我们感到非常吃惊的是，这样的人有很多甚至包括组织的一个副总。每个用户都收到了一封邮件提示他们选择难以猜到的密码有什么好处，另外开发人员迅速的使用了一种更安全的密码加密机制。】

         请 回忆一下我们在第三章中提到的彩虹表技术，恶意的用户如果能够访问到数据库就能使用这个技术来确定用户的密码。这些（以及其它的）黑客技术都是使用了哈希 算法的结果都是确定的这一特点——即相同的输入必然会产生相同的输出，所以攻击者如果尝试足够的输入，他们可能会基于已知的输入匹配到未知的输出。

        

         一种通用且高效的方法来添加安全层加密密码就是包含 salt （这个单词就是盐的意思，但为了防止直译过来反而不好理解，这里直接使用这个单词——译者注）。 Salt 是第二个明文组件，它将与前面提到的明文密码一起进行加密以保证使用两个因素来生成（以及进行比较）加密的密码值。选择适当的 salt 能够保证两个密码不会有相同的编码值，因此可以打消安全审计人员的顾虑，同时能够避免很多常见类型的密码暴力破解技术。

         比较好的使用 salt 的实践不外乎以下的两种类型：

l  使用与用户相关的数据按算法来生成——如，用户创建的时间；

l  随机生成的，并且与用户的密码一起按照某种形式进行存储（明文或者双向加密）。（所谓的双向加密 two-way encrypte ，指的是加密后还可以进行解密的方式——译者注）

如下图就展现了一个简单的例子，在例子中 salt 与用户的登录名一致：

 【需要记住的是 salt 被添加到明文的密码上，所以 salt 不能进行单向的加密，因为应用要查找用户对应的 salt 值以完成对用户的认证。】

         Spring Security 为我们提供了一个接口 o.s.s.authentication.dao.SaltSource ，它定义了一个方法根据 UserDetails 来返回 salt 值，并提供了两个内置的实现：

l  SystemWideSaltSource 为所有的密码定义了一个静态的 salt 值。这与不使用 salt 的密码相比并没有提高多少安全性；

l  ReflectionSaltSource 使用 UserDetails 对象的一个 bean 属性得到用户密码的 salt 值。

鉴于 salt 值应该能够根据用户数据得到或者与用户数据一起存储， ReflectionSaltSource 作为内置的实现被广泛使用。

配置salted 密码

         与前面配置简单密码加密的练习类似，添加支持 salted 密码的功能也需要修改启动代码和 DaoAuthenticationProvider 。我们可以通过查看以下的图来了解 salted 密码的流程是如何改变启动和认证的，本书的前面章节中我们见过与之类似的图：

 让我们通过配置 ReflectionSaltSource 实现 salt 密码，增加密码安全的等级。

声明 SaltSource Spring bean

         在 dogstore-base.xml 文件中，增加我们使用的 SaltSource 实现的 bean 声明：

 

<
bean
 
class
=
"org.springframework.security.authentication.dao.ReflectionSaltSource"
 
id
=
"saltSource"
>
  <
property
 
name
=
"userPropertyToUse"
 
value
=
"username"
/>
</
bean
>

 我们配置 salt source 使用了 username 属性，这只是一个暂时的实现，在后面的练习中将会进行修正。你能否想到这为什么不是一个好的 salt 值吗？

将 SaltSource 织入到 PasswordEncoder 中

         我们需要将 SaltSource 织入到 PasswordEncoder 中，以使得用户在登录时提供的凭证信息能够在与存储值进行比较前，被适当的 salted 。这通过在 dogstore-security.xml 文件中添加一个新的声明来完成：

 

<
authentication-manager
 
alias
=
"authenticationManager"
>
  <
authentication-provider
 
user-service-ref
=
"jdbcUserService"
>
    <
password-encoder
 
ref
=
"passwordEncoder"
>
      <
salt-source
 
ref
=
"saltSource"
/>
    </
password-encoder
>
  </
authentication-provider
>
</
authentication-manager
>

 你如果在此时重启应用，你不能登录成功。正如在前面练习中的那样，数据库启动时的密码编码器需要进行修改以包含 SaltSource 。

增强 DatabasePasswordSecurerBean

         与 UserDetailsService 引用类似，我们需要为 DatabasePasswordSecurerBean 添加对另一个 bean 的引用（即 SaltSource ——译者注），这样我们就能够为用户得到合适的密码 salt ：

 

public
 
class
 DatabasePasswordSecurerBean 
extends
 JdbcDaoSupport {
  @Autowired
  private
 PasswordEncoder passwordEncoder;
  @Autowired
  private
 SaltSource saltSource;
  @Autowired
  private
 UserDetailsService userDetailsService;

  public
 
void
 secureDatabase() {
    getJdbcTemplate().query("select username, password from users"
,
                             new
 RowCallbackHandler(){
      @Override
      public
 
void
 processRow(ResultSet rs) 
throws
 SQLException {
        String username = rs.getString(1
);
        String password = rs.getString(2
);
        UserDetails user =
          userDetailsService.loadUserByUsername(username);
        String encodedPassword =
          passwordEncoder.encodePassword(password,
          saltSource.getSalt(user));
        getJdbcTemplate().update("update users set password = ?
          where username = ?",
        encodedPassword,
          username);
        logger.debug("Updating password for
 username:
                     "+username+"
 to: "+encodedPassword);
      }
});
}
}

 回忆一下， SaltSource 是要依赖 UserDetails 对象来生成 salt 值的。在这里，我们没有数据库行对应 UserDetails 对象，所以需要请求 UserDetailsService （我们的 CustomJdbcDaoImpl ）的 SQL 查询以根据用户名查找 UserDetails 。

         到这里，我们能够启动应用并正常登录系统了。如果你添加了一个新用户并使用相同的密码（如 admin ）到启动的数据库脚本中，你会发现为这个用户生成的密码是不一样的，因为我们使用用户名对密码进行了 salt 。即使恶意用户能够从数据库中访问密码，这也使得密码更加安全了。但是，你可能会想为什么使用用户名不是最安全的可选 salt ——我们将会在稍后的一个练习中进行介绍。

增强修改密码功能

         我们要完成的另外一个很重要的变化是将修改密码功能也使用密码编码器。这与为 CustomJdbcDaoImpl 添加 bean 引用一样简单，并需要 changePassword 做一些代码修改：

 

public
 
class
 CustomJdbcDaoImpl 
extends
 JdbcDaoImpl {
  @Autowired
  private
 PasswordEncoder passwordEncoder;
  @Autowired
  private
 SaltSource saltSource;
  public
 
void
 changePassword(String username, String password) {
    UserDetails user = loadUserByUsername(username);
    String encodedPassword = passwordEncoder.encodePassword
      (password, saltSource.getSalt(user));
    getJdbcTemplate().update(
      "UPDATE USERS SET PASSWORD = ? WHERE USERNAME = ?"
,
      encodedPassword, username);
  }

 这里对 PasswordEncoder 和 SaltSource 的使用保证了用户的密码在修改时，被适当的 salt 。比较奇怪的是， JdbcUserDetailsManager 并不支持对 PasswordEncoder 和 SaltSource 的使用，所以如果你使用 JdbcUserDetailsManager 作为基础进行个性化，你需要重写一些代码。

 

配置自定义的 salt source

         我们在第一次配置密码 salt 的时候就提到作为密码 salt ， username 是可行的但并不是一个特别合适的选择。原因在于 username 作为 salt 完全在用户的控制下。如果用户能够改变他们的用户名，这就使得恶意的用户可以不断的修改自己的用户名——这样就会重新 salt 他们的密码——从而可能确定如何构建一个伪造的加密密码。

         更安全做法是使用 UserDetails 的一个属性，这个属性是系统确定的，用户不可见也不可以修改。我们会为 UserDetails 对象添加一个属性，这个属性在用户创立时被随机设置。这个属性将会作为用户的 salt 。

扩展数据库 scheama

         我们需要 salt 要与用户记录一起保存在数据库中，所以要在默认的 Spring Security 数据库 schema 文件 security-schema.sql 中添加一列：

 

create
 
table
 users(
  username varchar_ignorecase(50) not
 
null
 
primary
 
key
,
  password
 varchar_ignorecase(50) 
not
 
null
,
  enabled boolean not
 
null
,
  salt varchar_ignorecase(25) not
 
null
  );

 接下来，添加启动的 salt 值到 test-users-groups-data.sql 脚本中：

 

insert
 
into
 users(username, 
password
, enabled, salt) 
values
 (
'admin'
,'
admin',true
,
CAST
(RAND()*1000000000 
AS
 
varchar
));
insert
 
into
 users(username, 
password
, enabled, salt) 
values
 (
'guest'
,'
guest',true
,
CAST
(RAND()*1000000000 
AS
 
varchar
));

 要注意的是，需要用这些新的语句替换原有的 insert 语句。我们选择的 salt 值基于随机数生成——你选择任何随机 salt 都是可以的。

修改 CustomJdbcDaoImpl UserDetails service 配置

         与本章前面讲到的自定义数据库模式中的步骤类似，我们需要修改从数据库中查询用户的配置以保证能够获得添加的“ salt ”列的数据。我们需要修改 dogstore-security.xml 文件中 CustomJdbcDaoImpl 的配置：

 

<
beans:bean
 
id
=
"jdbcUserService"
  class
=
"com.packtpub.springsecurity.security.CustomJdbcDaoImpl"
>
  <
beans:property
 
name
=
"dataSource"
 
ref
=
"dataSource"
/>
  <
beans:property
 
name
=
"enableGroups"
 
value
=
"true"
/>
  <
beans:property
 
name
=
"enableAuthorities"
 
value
=
"false"
/>
  <
beans:property
 
name
=
"usersByUsernameQuery"
>
    <
beans:value
>
select username,password,enabled,
                 salt from users where username
 = ?
    </
beans:value
>
  </
beans:property
>
</
beans:bean
>

 

重写基础的 UserDetails 实现

         我们需要一个 UserDetails 的实现，它包含与用户记录一起存储在数据库中的 salt 值。对于我们的要求来说，简单重写 Spring 的标准 User 类就足够了。要记住的是为 salt 添加 getter 个 setter 方法，这样 ReflectionSaltSource 密码 salter 就能够找到正确的属性了。

 

 

package
 com.packtpub.springsecurity.security;
// imports
public
 
class
 SaltedUser 
extends
 User {
  private
 String salt;
  public
 SaltedUser(String username, String password,
                    boolean
 enabled,
    boolean
 accountNonExpired, 
boolean
 credentialsNonExpired,
    boolean
 accountNonLocked, List<GrantedAuthority>
            authorities, String salt) {
    super
(username, password, enabled,
          accountNonExpired, credentialsNonExpired,
    accountNonLocked, authorities);
    this
.salt = salt;
  }
  public
 String getSalt() {
    return
 salt;
  }
  public
 
void
 setSalt(String salt) {
    this
.salt = salt;
  }
}

 我们扩展了 UserDetails 使其包含一个 salt 域，如果希望在后台存储用户的额外信息其流程是一样的。扩展 UserDetails 对象与实现自定义的 AuthenticationProvider 时经常联合使用。我们将在第六章：高级配置和扩展 讲解一个这样的例子。

 

扩展 CustomJdbcDaoImpl 功能

         我们需要重写 JdbcDaoImpl 的一些方法，这些方法负责实例化 UserDetails 对象、设置 User 的默认值。这发生在从数据库中加载 User 并复制 User 到 UserDetailsService 返回的实例中：

 

public
 
class
 CustomJdbcDaoImpl 
extends
 JdbcDaoImpl {
  public
 
void
 changePassword(String username, String password) {
getJdbcTemplate().update(
    "UPDATE USERS SET PASSWORD = ? WHERE USERNAME = ?"
     password, username);
}
@Override
protected
 UserDetails createUserDetails(String username,
          UserDetails userFromUserQuery,
          List<GrantedAuthority> combinedAuthorities) {
          String returnUsername = userFromUserQuery.getUsername();
          if
 (!isUsernameBasedPrimaryKey()) {
              returnUsername = username;
      }
  return
 
new
 SaltedUser(returnUsername,
    userFromUserQuery.getPassword(),userFromUserQuery.isEnabled(),
    true
, 
true
, 
true
, combinedAuthorities,
    ((SaltedUser) userFromUserQuery).getSalt());
}
@Override
protected
 List<UserDetails> loadUsersByUsername(String username) {
      return
 getJdbcTemplate().
      query(getUsersByUsernameQuery(),
      new
 String[] {username},
      new
 RowMapper<UserDetails>() {
          public
 UserDetails mapRow(ResultSet rs, 
int
 rowNum)
                             throws
 SQLException {
             String username = rs.getString(1
);
             String password = rs.getString(2
);
             boolean
 enabled = rs.getBoolean(
3
);
             String salt = rs.getString(4
);
             return
 
new
 SaltedUser(username, password,
               enabled, true
, 
true
, 
true
,
               AuthorityUtils.NO_AUTHORITIES, salt);
            }
        });
  }
}

 createUserDetails 和 loadUsersByUsername 重写了父类的方法——与父类不同的地方在代码列表中已经着重强调出来了。添加了这些变化，你可以重启应用并拥有了更安全、随机的 salt 密码。你可能会愿意加一些日志和实验，以查看应用运行期间和启动时用户数据加载时的加密数据变化。

         要记住的是，尽管在这个例子中说明的是为 UserDetails 添加一个简单域的实现，这种方式可以作为基础来实现高度个性化的 UserDetails 对象以满足应用的业务需要。对于 JBCP Pets 来说，审计人员会对数据库中的安全密码感到很满意——一项任务被完美完成。