000031049 - Users are getting challenge questions for authentication after reset, where blank screen is displayed in RSA Adaptive Authentication (Hosted)

Document created by RSA Customer Support Employee on Mar 7, 2017Last modified by RSA Customer Support Employee on Apr 22, 2017
Version 2Show Document
  • View in full screen mode

Article Content

Article Number000031049
Applies ToRSA Product Set: Adaptive Authentication (Hosted)
RSA Product/Service Type: Adaptive Authentication (Hosted)
 
IssueUsers who have been reset and/or requires a new collection, are being challenged while in this state.
Example of a customer description might be similar to:
"Users are coming up with the blank screen for challenge questions when they first login."
CauseEngineering has reproduced the issue and under the conditions, which are primarily:
1. KBA has maxed out attempts and then is blocked.
2. SECRET(Challenge) questions are not in RSA system profile for this user (due to authentication method  reset, previous collection had expired or a new user who has never been collected.) 
This leads to next transaction of an AAH response REDIRECT_AUTHENTICATE because the risk score of the transaction is above the authentication rule in place for the FI. 
There are various ways this can show itself --
1. A blank page of challenge question method is trying to authenticate when the transaction has a risk score above the authentication rule above the threshold example if set to 600  any Risk Score >600 . 
2. Attempts to collect secret questions when this method has not been collected in the past, either because the FI is not using secret questions in their FI (which the region does have secret questions enabled).



 
Resolution1.  Obtain user ids for affected users, and then open a SaaS operations case and ask for "user history, including authentications, customer support activities, collections."
2. Ask the customer for the history of these users, whatever the user experiences during logins. 
3. Login to the back office and look at the customer support module for these users, look at available/blocked/resets for authentication methods. 
In particular look for KBA authentication blocked now or recently, while challenge questions method is also blocked. 
This state can be removed if the KBA method is blocked by unblocking the KBA authentication type first. 
Then resetting the user for authentication data (secret questions), so that at the next login below the Collection Risk Score threshold, the user will get collected  ( or if the back office is configured, to do a collection on the user. )
Customer service representatives should be made aware of the conditions that create the behavior, as it is by design, and perform the above steps to get the user back into all methods available and questions collected. 
Workaround1. Code can be added on client-banking side to utilize the analyze response  Authentication method flag(userStatus)  "LOCKED" to  lock the account on banking side, or other actions to make sure authentication attempts do not occur. 
2. It has been seen that if secret questions were available in the region, enabled in the FI but the Authentication method was not setup, there could be attempts to collect secret questions, instead of trying to authenticate. 
Notes
  • What R&D has seen happen after the Unblock(reset of the method) is the AUTH_METHOD_STATUS . FAILURE_COUNTER column is set to zero,  then the user will go through the KBA authentication ( since KBA does not require collection ) 
  • KBA cannot be reset, the method is always available and can get blocked after so many attempts fail, and then can be unblocked in RSA BackOffice Customer Support module.
  • Other methods like Phone, OOB, or OTP (SMS or email) maybe affected by these conditions, but since they may have data retained by the customer and RSA cannot do as much troubleshooting with these methods, however, generally, follow the same as with challenge questions, do a reset so they are then collected. 

Attachments

    Outcomes