Announcement Announcement Module
Collapse
No announcement yet.
Salt, based on password Page Title Module
Move Remove Collapse
This topic is closed
X
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Salt, based on password

    Hi

    How can I setup Acegi to use the entered password as the salt when decoding the password? the SaltSource interface provides the UserDetails, but I cannot find the entered password in this, "only" the password retrieved by my implementation of AuthenticationDao (witch is the encrypted version). So making my own implementation of SaltSource, is not an option.

    I know, that basing the salt on the uncoded password, means that there is no way of retrieving the password, if the user has forgotten it (thats the way I want it to be ).

    Thanks in advance

    /Morten

  • #2
    There's no way of de-hashing the md5 or sha password encoders either, even without a salt.

    The salt just gets "sprinkled" on the input to cause the output to look different than just hashing the password. The pupose of the salt is to keep two people with the same password from showing the same hash in the database.

    Take a look at using the net.sf.acegisecurity.providers.dao.salt.Reflection SaltSource.
    You can specifiy the "userPropertyToUse" property as a method name, such as "getUserId". You should use a value that will not change through the life of that UserDetails object. The database ID of that user is a good choice. The important thing is to use something that won't change.

    Comment


    • #3
      Yes, as Ray said, something like a database identifier is ideal as it is synthetic with no business meaning. That translates into it won't change too often. You should be aware of a downside of one-way hashes: you can't use Digest authentication with them. This might be a problem if you, say, want to expose a WebDAV application where Digest is mandatory.

      Comment


      • #4
        Originally posted by RayKrueger
        There's no way of de-hashing the md5 or sha password encoders either, even without a salt.

        The salt just gets "sprinkled" on the input to cause the output to look different than just hashing the password. The pupose of the salt is to keep two people with the same password from showing the same hash in the database.

        Take a look at using the net.sf.acegisecurity.providers.dao.salt.Reflection SaltSource.
        You can specifiy the "userPropertyToUse" property as a method name, such as "getUserId". You should use a value that will not change through the life of that UserDetails object. The database ID of that user is a good choice. The important thing is to use something that won't change.
        After reading your reply, I realised that I knew close to nothing about one-way hash encryption. After reading up on the subject, I see that the question was, well lets say it as it is, stupid.

        Also basing the salt on the same field, wont avoid equal digested passwords values :roll:

        I am still a little confused about the purpose of the net.sf.acegisecurity.providers.dao.salt.SystemWide SaltSource class, it says :

        Originally posted by javadoc
        Does not supply a different salt for each User . This means users sharing the same password will still have the same digested password. Of benefit is the digested passwords will at least be more protected than if stored without any salt.
        Why is it more protected? Guess that if a hacker knows the min lengt of a password, it “easier” to crack the calculated hash



        Thanks for the reply

        Comment


        • #5
          Originally posted by mf1616
          I am still a little confused about the purpose of the net.sf.acegisecurity.providers.dao.salt.SystemWide SaltSource class, it says :

          Originally posted by javadoc
          Does not supply a different salt for each User . This means users sharing the same password will still have the same digested password. Of benefit is the digested passwords will at least be more protected than if stored without any salt.
          Why is it more protected? Guess that if a hacker knows the min lengt of a password, it “easier” to crack the calculated hash
          It's of limited additional protection, but at least it means your hashed database columns aren't identical to every other MD5 or SHA hashed versions of the same cleartext passwords. It just introduces a small amount of database obfuscation over a hashed but non-salted password. I personally wouldn't bother. If you're using using one way hashes, your security requirements are sufficient to justify a per-user salt. If your security requirements aren't at that level, stick to cleartext passwords to avoid limiting your future options (eg password recovery emails - which I know aren't secure but many people expect this type of functionality; Digest authentication etc).

          Comment


          • #6
            The md5 hash of the word 'password' is always:
            5f4dcc3b5aa765d61d8327deb882cf99

            The SHA hash of 'password' is always going to be:
            5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8

            Using a salt makes those two facts false

            Comment

            Working...
            X