Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    13.1p storeWithHash Default

    Hi Isomorphic,

    Did you make a change around the default behavior of password type fields with respect to storeWithHash in 13.1p?

    We use a PasswordItem for a field of type password, and we are seeing the expected behavior coming from the client, but somewhere down in IDACall.handleDSRequest, the password is being hashed by default now.

    We do not need the framework to do this, as we manage this ourselves.

    This appears to be a change in behavior and a breaking change for us.

    We tried adding storeWithHash="" in the ds.xml for the password type field, however, we get some server-side exceptions and a "MessageDigest not available" in the response.

    Can you recommend what we need to do to restore the 12.1p behavior?

    Thank you

    #2
    Hi Isomorphic,
    Do you have an update for us on this one?
    Thank you

    Comment


      #3
      You can actually force no hash to be applied by specifying storeWithHash as "none". This has been in place since the change to use "bcrypt" by default but was undocumented.

      We've now documented it and will also update the associated schema, but you don't have to wait for those changes to appear in a build to use "none".

      Comment


        #4
        You can see the back compatibility release note for this change here. Just search for "storeWithHash" at the top.

        Sorry we didn't document "none" originally but we were trying to promote good security practices and it was thought that "none" might be used to store plaintext passwords rather than by advanced customers like you who have developed their own hashing solution.

        Comment


          #5
          Thank you.
          No worries, we applied the none option, and everything is working as expected now.

          Comment

          Working...
          X