Password Attempt Account Lockout for "Change CA Single Sign-On User Password"

[David Dixon]

Maybe I'm missing something, but it appears like if you expose this new assertion as part of 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

[Mark ODonohue]

Hi David 

 

The assertion : (added in Gateway 9.3 CR3) 

Change CA SSO User Password Assertion - CA API Gateway - 9.3 - CA Technologies Documentation 

 

would be using the : CA Single Sign On DMS Api 

Delegated Management Services API - CA Single Sign-On - 12.7 - CA Technologies Documentation 

 

I see the assertion has this note : 

The reasonCode context variable is set only if SmDmsUser#changePassword(String newPassword, String oldPassword, boolean doNotRequireOldPassword) method in DMS API fails. If the assertion fails for any other reason (that is, it cannot connect to CA Policy Server, it cannot find user in the user directory, and so on), the reasonCode context variable is not set.

 

But that the assertion does not specify the "doNotRequireOldPassword" value (at least in the documentation) -  So I expect it is set to false.  

 

To use the DMS Api functions there is a two step process :

     a) First you need to login, using UN / OldPW 

     b) And then execute the changePassword function.  using (UN/ OldPW/ NewPW)

 

Step a) the login to SSO will trigger all the normal password failure methods for any normal SSO login and lockout etc. 

 

Step b) for non admin user will give an error if you try and specify another user or doNotRequireOldPassword=true.

 

So I am fairly sure you are safe.

 

However, for the raw DMS Api function, if you login as an SSO admin user, they can change other users passwords, and they can also specify the doNotRequreOldPassword=true, to overwrite passwords without checking - but that does not seem how this function is wrapped in the assertion. 

 

But I will have to upgrade to CR3 in my install and check ( that may not happen today, but should be able to get back early next week). 

 

Cheers - Mark

PS: The most common reason for failure is that there is some problem with the new password such as it does not meet complexity requirements or is previously used. 

[Stephen Hughes]

Good afternoon,

 

Were you able to resolve the issue? What was the final result?

 

Sincerely,

Stephen Hughes
Broadcom Support