PasswordDigest authentication on stored MD5 password

[dashout]

Hi all,

I have a spring web-application that uses Acegi based authentication. the password is stored in the database as MD5 encrypted password and use the DaoAuthenticationProvider and Md5PasswordEncoder password encoder for authentication. It is all fine till this point.

Now, A few operations of the application is exposed using Spring WS, having the XWS Security Interceptor configured to authenticate using UsernameToken with PlainText Password (using AcegiPlainTextPasswordValidationCallbackHandler injecting the same authenticationManager used by the web-application).

As 'plain text' passwords are not 'safe' , i had to move to PasswordDigest based authentication.
But AcegiDigestPasswordValidationCallbackHandler supports injection of UserDetailsService rather than having Authentication ProviderManager injected.

I understand it is the way PasswordDigests work, ie, PasswordDigests validate by creating SHA-1 hashed password of the user password with and compares with the user's actual password.

But can someone please help me point out where my mistake is?
Isn't it normal to have passwords stored in DB as MD5 digests? How to use PasswordDigest based Spring-WS authentication against such already-hashed passwords?

[tareq]

You can't due to how ws-security digest passwords work. There is a different random string (a nonce) passed with the digest password for every request. On the server side, the framework security needs to apply the random nonce to the stored password and compare it to the digest. Therefore, you have to store clear passwords in this case.

[vbose]

You could extend JdbcDaoImpl from Spring Security by overiding the createUserDetails API to achieve what you really intended to achieve. I have a use case where I store encrypted password in the database. I am using Jasypt instead of MD5. See the example below. I decrypt the encrypted user's password before the user object is created and sent to the UI layer. I am also using password digest username token in the soap header.

/**

 * EisUsersJdbcDaoImpl.java : This implementation overrides some behavior of Spring Security's {@link JdbcDaoImpl}

 * which retrieves the user details (username, password, enabled flag, and authorities) from a database

 * using JDBC queries.

 * @author Vigil Bose

 */

public class EisUsersJdbcDaoImpl extends JdbcDaoImpl {

 

      @Autowired

      @Qualifier("strongEncryptor")

      private PBEStringEncryptor strongEncryptor;

     

     

       /**

     * The API createUserDetails() is overridden to apply decryption algorithm to the password before creating the final

     * UserDetailsObject returned from <tt>loadUserByUsername</tt>.

     *

     * @param username the name originally passed to loadUserByUsername

     * @param userFromUserQuery the object returned from the execution of the

     * @param combinedAuthorities the combined array of authorities from all the authority loading queries.

     * @return the final UserDetails which should be used in the system.

     */

      @Override

    public UserDetails createUserDetails(String username, UserDetails userFromUserQuery,

            GrantedAuthority[] combinedAuthorities) {

        String returnUsername = userFromUserQuery.getUsername();

 

        if (!isUsernameBasedPrimaryKey()) {

            returnUsername = username;

        }

        //Decrypt the encrypted password

        String decryptedPassword = this.strongEncryptor.decrypt(userFromUserQuery.getPassword());

       

        return new User(returnUsername, decryptedPassword, userFromUserQuery.isEnabled(),

                true, true, true, combinedAuthorities);

    }

}