使用 Spring Security 3.1 进行 2 路加密答案

【问题标题】：2 way encryption with Spring Security 3.1使用 Spring Security 3.1 进行 2 路加密
【发布时间】：2012-02-09 22:40:54
【问题描述】：

Spring Security 3.1 有一个漂亮而方便的方法来在 XML 配置中包含所需的哈希，这就像一个魅力：

<bean id="securityDataSource" class="org.springframework.jndi.JndiObjectFactoryBean">
    <property name="jndiName" value="java:comp/env/myDataSource"/>
    <property name="resourceRef" value="true"/>
</bean>

<bean id="encoder" class="org.springframework.security.crypto.password.StandardPasswordEncoder" />

<security:authentication-manager>
    <security:authentication-provider>
        <security:password-encoder ref="encoder" />
        <security:jdbc-user-service 
            data-source-ref="securityDataSource"
            authorities-by-username-query="SELECT username, authority FROM user_roles WHERE username = ?"
            users-by-username-query="SELECT username, password, enabled FROM users WHERE username = ?"
        />        
    </security:authentication-provider>
</security:authentication-manager>

我查看了这个 StandardPasswordEncoder 类，它有两个适用的公共方法：encode() 和 matches()。 match() 方法大概是 spring 用来比较输入密码的散列版本和数据库中的散列密码。 encode() 方法似乎用于生成哈希字符串以存储在数据库中。我假设您可以使用它来随意生成或更改密码。

我的问题是：如果有完全正当的理由这样做，用双向加密方法替换这个哈希会有多困难（或者说有可能）？我不想牺牲此 Spring 安全配置提供的所有功能和便利性，但有必要（根据业务用户）随意访问纯文本密码。

【问题讨论】：

标签： spring encryption hash passwords spring-security

【解决方案1】：

只要您提供PasswordEncoder 接口的实现，Spring Security 就会很高兴。它不关心密码是散列还是可逆加密。

您当然需要授予您的实现对密钥的访问权限以验证密码。这将是一个额外的配置问题和安全风险。另一种方法是使用非对称密钥对其进行加密，但也使用here 所述的哈希。

所以不，这并不难。这是一个好主意与否是另一回事。我很想知道业务需求是什么。

【讨论】：

卢克，你是对的。很难为 PasswordEncoder 实现安全的可逆加密“matches()”方法。更不用说 Spring 没有提供自己的此类实现无疑是有原因的。您的链接提供了很好的见解，尽管最终我不喜欢使用非对称密钥加密和散列的想法。维护太多。