As part of our requirements, I have enabled the below policies for “Password” field in IDM.
Min length
Max length
Regex
Password history (should not be same as last 4)
Once this is setup, I am trying a simple journey with Platform Username, Platform Password and Patch Object.
As part of Platform Password node, if I give invalid password, I get errors as part of the same callback for Min length, Max length and Regex.
However, I do not get any errors for Password history. But once the journey moves to Patch Object, I get a “401, Failed Policy evaluation” error, and the journey fails.
I ideally want this error as part of Platform Password node, in order to show relevant error to users. Please let me know if I am missing any configuration required for this.
P.S: The password history policy seems to be setup fine. Since I get the failed policy name for Password history as expected if I directly hit “validateObject” endpoint.
There is a reason for this… the password history is maintained at the repository. Your syntax rules are maintained in the web application and simply validated. It is the repository’s password policy that is throwing the exception. Thus, only seen at the time of your patch object.
If you wanted to “dynamically” confirm against the password history… that would become complicated.
Maintain the parseable history in the downloaded JS… now you have other worries.
Maintain the password history in the User JWT?? bigger worries.
Perform a comparison against the “remote” password history for each attempt, prior to the patch? Again, complicated.
Many have worked on custom solutions for this need. (Purposely not using the word, requirement). Perhaps someone can provide their “legitimate and secure” approach.
Getting away from the patch node. Use a decision script to patch IDM directly (which is even easier now that scripting next gen brings the ‘openidm’ interface).
Capturing 403 with Policy requirements, then loop back to the page node with the error message.
It’s not fully interactive, though. The password history validation in our solution is within IDM control . Which means we could make it easily interactive if we wanted to.
However, providing immediate feedback on history does not really bothers me - I know for sure the passwords I have used in the past, don’t I?
Also note the OWASP recommended approach - the authority in this matter - regarding password strength:
Consider using zxcvbn as an algorithmic alternative to password composition policy — it is more secure, flexible, and usable when sites require a minimal complexity score in place of annoying rules like "passwords must contain three of {lower, upper, numbers, symbols}
IDM password validation can’t certainly deal with fluid password requirements - so someway, we would have to bake our own custom policy leveraging this library - and provide the feedback from the AM journey.
Thank you for the suggestions. Using zxcvbn is a very interesting alternative. However, we have stringent requirements due to compliance and had to stick to the conventional method of enforcing complexity.
Performing the patch operation in a scripted decision node and looping back to password collection page would have been a good option.
However, it turned out that we had another requirement wherein we collect the password from the front end in an encrypted format and decrypt it at our end in the journey. So, in this case, we couldn’t make use of the inbuilt Platform Password along with validations.
So, we instead used the openidm action validateProperty along with a ValidatedCreatePasswordCallback in a scripted decision node to get around this. validateProperty gives us a list of failed policies in a format that is expected by ValidatedCreatePasswordCallback (including the password history validation).