Announcement Announcement Module
No announcement yet.
What is the most appropriate use of StandardPasswordEncoder for salting passwords? Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • What is the most appropriate use of StandardPasswordEncoder for salting passwords?

    I would like to add password salting to a site I am working on, and I discovered that Spring Security 3.1 has some new features to make this very easy to do.

    I have a question about the StandardPasswordEncoder class. It operates a little differently than I would expect. It seems simpler to use than coding the salting myself, but I think there's some "magic" going on that I don't understand.

    StandardPasswordEncoder seems to randomly salt the hash for me, which is fine. But upon matching the original password to the encoded password... how is it able to match the passwords without knowing what the original salt was in the first place?

    It is to my understanding that once you make a salt, you can't go back... so if there's a random salt to generate the encoded hash in the first place... how is StandardPasswordEncoder able to match the password at a later point? I am confused. Shouldn't I have to get the salt, persist the salt in the database and then supply the salt when I authenticate? How is it able to do this without me storing and providing the salt value?

    Thanks for clearing up the confusion. I hope my question makes sense.

  • #2
    I also want to be more specific about my problem.

    I figured out that by using the StandardPasswordEncoder, I could use it once to create the salt, and then use it a second time to create a hashed password using the salt as a the "secret" constructor parameter.

    Maybe this overkill, but this is generally how I wanted to salt the passwords all along. At least it works and I know stuff is secure.

    Anyway, now I have my UserAccount object with 3 methods of interest:
    - generateSalt()
    - generateHashedPassword()
    - matchesPassword()

    These methods use the StandardPasswordEncoder class

    Now, I'd like to use these in an authentication provider, but I realized that the default one only takes a UserDetails interface... which is how I was doing it before. I should have looked to see how Spring Security wanted me to do this.

    Which is better:

    1. Should I rip out the default Authentication Provider and use my UserAccount matchesPassword() method? Assuming I do this approach, is this all I need?:

    @Component(value = "authenticationProvider")
    public class AuthenticationProviderImpl extends AbstractUserDetailsAuthenticationProvider {
        UserAccountManager userAccountManager;
        protected UserDetails retrieveUser(String username, UsernamePasswordAuthenticationToken authentication) throws AuthenticationException {
            return userAccountManager.loadUserByUsername(username);
        protected void additionalAuthenticationChecks(UserDetails userDetails, UsernamePasswordAuthenticationToken authentication) throws AuthenticationException {
            UserAccount userAccount = (UserAccount) userDetails;
            if(!userAccount.matchesPassword(authentication.getCredentials().toString())) {
                throw new BadCredentialsException("The username or password is incorrect.");
    2. Should I abandon my 3 methods and use an alternate approach that Spring Security provides out of the box in its default Authentication Manager? Is that as secure as my approach?

    Last edited by egervari; Apr 14th, 2011, 02:58 AM.