Layer7 API Management

  • Private Community

  • 1.  Change CA SSO User Password Assertion - SSO Password Policies?

    Posted Aug 16, 2018 12:13 PM

    Does anyone know if the new "Change CA SSO User Password Assertion" supports CA SSO Password Polices, and what the behavior will be if the password being set does not meet the password policy requirements?

     

    Thanks,

     

    Josh



  • 2.  Re: Change CA SSO User Password Assertion - SSO Password Policies?

    Posted Aug 16, 2018 01:31 PM

    Hi Josh,

     

    That is a great question! This was something that taught me some new stuff.

     

    I looked around at our internal functional specification for this assertion and I see a few errors specified for a use-case where the "new password is not valid” which specifies an example of "too weak”, so while it isn't explicitly called out about respecting the CA SSO password policy, it looks to me that it is indeed respected.

     

    In such a case where a password is "too weak”, an error will be thrown and the assertion will be marked as "falsified”, and of course then the password would not be changed on the CA SSO server.

     

    I hope the above helps answer your questions. Further to the above, I have asked our documentation team to call this out in the documentation on the assertion (which is here, by the way: Change CA SSO User Password Assertion - CA API Gateway - 9.3 - CA Technologies Documentation ).



  • 3.  Re: Change CA SSO User Password Assertion - SSO Password Policies?
    Best Answer

    Posted Aug 16, 2018 06:21 PM

    A quick update to my own reply from earlier:

     

    I was told recently when reviewing this with a colleague that if the assertion fails, the reasonCode will be set to the same code returned from the SiteMinder Java SDK. That SDK is documented here, for reference: https://support.ca.com/cadocs/0/CA%20SiteMinder%20r12%20SP2-ENU/Bookshelf_Files/HTML/javadoc-sm/com/netegrity/sdk/dmsapi/SmDmsUser.html#changePassword(java.lang.String,%20java.lang.String,%20boolean)

     

    You'll notice that from the returned reasonCode's listed in that SDK, it definitely works with a password policy that may be set on the CA SSO server.

     

    From the SDK notes, here are the possible reasonCode's from a change request that doesn't match a password policy set:

     

    If the change password request fails, SmApiResult may contain one of the reason codes below. These reason codes indicate a violation of a password policy:

     

    0. No failure reason.

    1. Change of password is required.

    1000. General failure.

    1001. Password is too short.

    1002. Password is too long.

    1003. The old password is bad.

    1004. Password has already been used.

    1005. Password is too similar to a previous password.

    1006. Password has too many repeating characters.

    1007. Password contains a disallowed word from the password dictionary.

    1008. Password has too few alphabetic characters.

    1009. Password has too few numeric characters.

    1010. Password has too few alphanumeric characters.

    1011. Password has too few punctuation mark characters.

    1012. Password has too few non-printable characters.

    1013. Password has too few non-alphanumeric characters.

    1014. Password contains text that matches too many consecutive characters in the user's directory entry.

    1015. The grace period has been exceeded for allowing user login after the user's password has expired.

    1016. PIN is a system-generated PIN.

    1017. PIN is too long.

    1021. PIN is accepted.

    1022. Password has too few lower case letters.

    1023. Password has too few upper case letters.

    1024. Password cannot contain lower case letters.

    1025. Password cannot contain upper case letters.

    1026. Password cannot contain digit characters.

    1027. Password cannot contain punctuation characters.

    1028. Password cannot contain non-printable characters.

    1029. Password cannot contain non-alphanumeric characters.

    1030. Password cannot contain alphanumeric characters.

    1031. Password must not match the disallowed regular expression(s).

    1032. Password does not match the required regular expression(s)

    1033. PIN is too short.

    1034. PIN can contain only digit characters.

    1035. PIN can contain only alphanumeric characters.



  • 4.  Re: Change CA SSO User Password Assertion - SSO Password Policies?

    Posted Sep 19, 2018 03:57 PM

    Maybe I'm missing something, but it appears like if you expose this as a service for a change password process on your front end, that you could potentially be allowing for brute force attempts against your accounts.  Any "bad" attempt at the old password should count against the "failed attempts" on the account, however, this assertion does not do that, nor does it lock/disable the account like it should.  Further, it appears that it is evaluating the contents of the new password first.  This means there is yet another way of brute forcing this assertion by brute forcing against the new password until "this is too similar to the current/old password" is received.  

     

    Can someone tell me if I'm misunderstanding something? We want to use this, but as it stands, it opens us up to automated brute force attacks.

     

    Thanks,

    Dave



  • 5.  Re: Change CA SSO User Password Assertion - SSO Password Policies?

    Posted Sep 27, 2018 04:35 PM

    Hi David,

     

    I'm not super familiar with the SSO stuff myself (I'm going to try to get a team member to chime in here later), but my initial understanding of your concern is that you fear brute force attempts could be introduced as a result of this assertion. The assertion, as far as I'm aware acts more like a proxy to the SSO server for handling user password changes and other items. I don't believe the assertion itself is doing the validation, it would instead pass it back to the SSO server for validation. So I'm not entirely sure if this would truly lead to a brute force attack, because that should theoretically already be properly handled by the backend SSO server. The assertion is simply calling the open APIs for this service on the SSO server, so I think these concerns are valid but I believe they would already be in play, it's just a matter of how publicly you expose the service. If you use it for your own employees and it can't be called from outside your network, then the risk of a large-scale brute force attack would seem quite low, at least in my opinion. Of course though, that won't be everyones use-case, so it can theoretically present a larger platform for access.