Announcement Announcement Module
No announcement yet.
PasswordEncoder gives different result Page Title Module
Move Remove Collapse
This topic is closed
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • PasswordEncoder gives different result

    I have read the threads on this board about PasswordEncoder, but I still can't figure out what my problem is.

    Here are the relevant sections on my config file:

    <bean id="daoAuthenticationProvider"
    class="net.sf.acegisecurity.providers.dao.DaoAuthe nticationProvider">
    <property name="authenticationDao">
    <ref bean="authenticationDao"/>
    <property name="passwordEncoder"><ref local="passwordEncoder" /></property>
    <property name="saltSource"><ref local="saltSource" /></property>

    <bean id="passwordEncoder" class="net.sf.acegisecurity.providers.encoding.Sha PasswordEncoder" />

    <bean id="saltSource" class="net.sf.acegisecurity.providers.dao.salt.Sys temWideSaltSource">
    <property name="systemWideSalt">
    Then in my register page I have code like:

    newUser.setPassword(getPasswordEncoder().encodePas sword(rawPassword, getSaltSource()));
    which then gets saved to the db.

    I seem to be getting the same salt source in my register page as does the login page, and the value seems to be saved in the db ok. But when I debug the app, I can see that the resulting encrypted value of the password in the login process is not the same as the stored value in the db, so then login always fails. If I take the encrypted value from the login process and just insert that value into the db, then login works.

    I must be doing something wrong with the salt or encryption in my register page. I have tried not using Base64 encoding but I didn't see any change. I have debugged the values during runtime, but I just can't figure out why I am getting two different values. Anyone have any ideas?

  • #2
    Ok it is definitely something with the salt. If I don't use salt, then it works. I am checking that I am getting the correct value for the salt source. It probably is a different instance on my register page than the login process. Would that matter?


    • #3
      I'm using the following and it works like a charm:
      	<bean id="saltSource" class="org.acegisecurity.providers.dao.salt.ReflectionSaltSource">
      		 <property name="userPropertyToUse"><value>getUsername</value></property> 
      cryptedPassword = EncodePasswordUtil.encodePassword(cleartextPassword, user.getLogin());
      In your case you can try:

      cryptedPassword = EncodePasswordUtil.encodePassword(rawPassword, "IAmTheSaltSource");
      Just to find out if getSaltSource() is maybe your issue.

      Hope this helps.


      • #4
        That does help, Asha'man. It did work if I just passed in a String in my code for the salt.

        My method "getSaltSource()" was returning the actual SaltSource object. I misunderstood that PasswordEncoder.encodePassword(String rawPass, Object salt) took a SaltSource object, but I think it takes the actual salt value.

        So instead of:
        passwordEncoder.encodePassword(rawPass, mySaltObject) ;
        I tried

        passwordEncoder.encodePassword(rawPass, mySaltObject.getSalt(authUser));
        and it worked.


        • #5
          Great. And it'll also work if you change the salt to use for example a property of the user as shown in my configuration example.

          So it's even better than my code example. Maybe I try your way even if it's unlikely that I will change the salt.


          • #6
            Great thread, now it works also in my system.

            BTW, I think it shall be stated in the docu how to use PasswordEncoder.encodePassword( rawPass, salt ), that as a salt one should use a string (salt's value) rather than SaltSource


            • #7
              If you think something is unclear, raise a JIRA issue. It's the best way to get things fixed.
              Last edited by karldmoore; Aug 29th, 2007, 12:27 PM.


              • #8
                Originally posted by Injecteer View Post
                Great thread, now it works also in my system.

                BTW, I think it shall be stated in the docu how to use PasswordEncoder.encodePassword( rawPass, salt ), that as a salt one should use a string (salt's value) rather than SaltSource
                It's pretty clear from the Javadoc for the encodePassword method that it's talking about a salt value:



                • #9
                  what I don't really understand is, why having the Salt param of Object type, if it's going to be mixed-in into a String.
                  Why not simply have it as String or as SaltSource? then you don't really have to document it a lot

                  I might imagine, that somewhere deep inside the Acegi, some private implementation of the PasswordEncoder might want to accept a String as an Object, but when you expose it in a PUBLIC interface, it looks, hmmm, not so good.


                  • #10
                    There's no reason to assume that a generic password encoder should be limited to String arguments as there's no reason why the salt should have to be a String. So it makes every sense for it not to be a String in a public interface where you do not know what type the salt is going to be or how the implementation is going to use it. As an example, the LdapShaPasswordEncoder requires that the salt is a byte array:


                    The SaltSource is an interface to allow an authentication provider to obtain the correct salt property from a retrieved UserDetails object before encoding the password so it wouldn't make sense to supply the SaltSource to the encoder.

                    When the two are used in combination, there is no guarantee in advance what type the object retrieved from the salt property will be, so again there is no reason why the authentication provider should be made responsible for performing the necessary conversion to the required String format. In fact it would be plain bad design as it has no way of knowing what type of password encoding is being used in the security database. If there is some kind of customized encoding in place, it makes sense for the details to be implemented in customized PasswordEncoder and UserDetails implementations.