Question

Spring Security 3.1 has a nifty and convenient way to include the desired hash in the XML configuration, which works like a charm:

<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>

I took a look at this StandardPasswordEncoder class, which has two applicable public methods: encode() and matches(). The matches() method is presumably used by spring to compare the hashed version of the inputed password with the hashed password in the database. The encode() method seems to be used to generate the hashed string to store in the database. I assume you could use this to generate or change the password at will.

My question is this: given a completely legitimate reason to do so, how difficult (or is it at all possible) would it be to substitute this hash with a two-way encryption method? I don’t want to sacrifice all of the power and convenience that this spring security configuration offers, but it is necessary (per the business users) to have access to the plain text password at will.

Answer 1

As long as you provide an implementation of the PasswordEncoder interface Spring Security will be happy. It won’t care whether the passwords are hashed or reversibly encrypted.

You would of course then need to give your implementation access to the key in order to verify passwords. That would be an additional configuration headache and security risk. An alternative would be to encrypt it using an asymmetric key but also use a hash as described here.

So no, it’s not difficult. Whether it’s a good idea or not is another matter. I’d be curious to know what the business requirement is.