2路加密使用Spring Security 3.1

的Spring Security 3.1有一个漂亮而方便的方法，包括在XML配置所需的哈希，这就像一个魅力：2路加密使用Spring Security 3.1

<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（）。 matches（）方法大概是由spring用来比较输入密码的哈希版本和数据库中的哈希密码。 encode（）方法似乎用于生成散列字符串以存储在数据库中。我假设你可以使用它来随意生成或更改密码。

我的问题是这样的：给定一个完全合法的理由这样做，是多么困难（或者是它在所有可能的），这将是一个双向加密方法来替代这个哈希？我不想牺牲今年春季安全配置所提供的所有强大功能和便利性，但有必要（根据业务用户）随意访问纯文本密码。

来源

2012-02-09 Bryan Larson

只要你提供PasswordEncoder接口的Spring Security的实现会很高兴。它不会在意密码是散列还是可逆加密。

你当然会那么需要给你实现访问密钥，以验证密码。这将是一个额外的配置头痛和安全风险。另一种选择是使用非对称密钥对其进行加密，但也可以使用散列here。

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

来源

2012-02-11 12:55:24

卢克，你是对的。对PasswordEncoder实施安全的可逆加密的“matches（）”方法将很困难。更不用说毫无疑问，Spring为什么不首先提供自己的这种实现。您的链接提供了良好的洞察力，虽然最终我不喜欢使用非对称密钥加密散列加的想法。维护方式太多。 – 2012-02-11 20:48:45

2路加密使用Spring Security 3.1

回答

相关问题