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

回答

相關問題