9 KBA and OTP Challenges

OTP Anywhere and KBA can be used alongside each other. OTP Anywhere can be used also to compliment KBA challenge or instead of KBA.

The chapter contains the following sections:

• Using KBA and OTP

• Risk Range for KBA and OTP

• KBA and OTP Scenarios

9.1 Using KBA and OTP

Oracle Adaptive Access Manager deployments may choose to use both KBA and OTP or each separately or no challenge mechanisms at all. If both KBA and OTP are being used in a deployment, the security team may choose to use OTP first for high risk situations and then fall back on KBA.

For example, a user logging in from a new IP address in a city he often logs in from is relatively low risk on its own, so a KBA challenge is a good option to gain additional verification that this is the valid user. If, however, a user is attempting a funds transfer of more than $1000 using a device and location he has never accessed from previously and the user has never performed a transfer, a stronger measure such as OTP Anywhere would be warranted.

If a customer has both KBA and OTP enabled, the priority is configurable through properties. The default is to OTP challenge first and then KBA challenge for high risk situations.

9.2 Risk Range for KBA and OTP

A KBA challenge is appropriate for the scores in the 500 to 700 risk range. An OTP challenge would have been appropriate for a score in the 701 to 900 range. For a score of 900 and over, the action triggered should be a "block." The user should be allowed to continue on if the score is under 500.

9.3 KBA and OTP Scenarios

KBA and OTP scenarios are presented in this chapter.:

• Always Challenge by Group

• CSR OTP Profile Reset with High Risk Always Challenge by Group

• Unregistered Low Risk User (Risk Score 500 or Below)

• Registered Low Risk User (Risk Score 500 or Below)

• Unregistered High Risk User (Risk Score Above 500)

• Registered High Risk User (Risk Score Above 500)

• Register High Risk Lockout

• High Risk Exclusion

• OTP Challenge with Multi-Bucket Patterns

9.3.1 Always Challenge by Group

If a group of users should be considered high risk every time they log in (regardless of other factors), a policy can be configured to always challenge the group of users with OTP (High Risk).

Administrator

1. Log in to OAAM Admin.

2. Create a "High Risk Users" group and add high risk users to the group.

3. Create an Action group "High Risk User" with the following values:

   Alert type: Fraud

   Alert level: High

   Alert message: High risk user login attempt

4. Create a policy with the following values:

   Policy Name: OAAM OTP RR

   Policy Status: Active

   Checkpoint: Post-Authentication

   Scoring Engine: Average

   Weight: 100

   Description: OAAM OTP Release Readiness Policy

5. Add a rule with the following general values:

   Rule Name: In High Risk Group

   Rule Status: Active

   Rule Notes: Checks if user is in high risk user group.

6. Specify the results for if the rule triggers:

   Score: 1000

   Weight: 100

   Action Group: OAAM Challenge

   Alert Group: High Risk User

7. Add the condition USER: User in Login Group with the following values:

   Is in group: True

   User Group: High Risk Users

User

Note:

User with user name "Henry" has already logged in once and completed registration.

"Henry" logs in to OAAM Server again. He is always challenged with SMS.

9.3.2 CSR OTP Profile Reset with High Risk Always Challenge by Group

A high risk login from a user, who is registered for KBA but has had his OTP profile reset by customer service, is challenged by other methods before he is allowed to register a new OTP profile.

Note:

The user "Henry" has had his OTP reset.

1. The user logs in to OAAM Server with the user name "Henry."

   He is challenged with KBA (since OTP is not registered).

2. He answers the challenge question.

3. He completes OTP Registration

4. Later, he logs in again with user name "Henry."

5. He is OTP Challenged.

9.3.3 Unregistered Low Risk User (Risk Score 500 or Below)

An unregistered user in a low or no risk login situation is asked to register his image/phrase, challenge questions, and OTP profile.

1. The user logs in to OAAM Server with user name "Stanley." "Stanley" is a low risk user.

   He is presented with the registration screens.

2. He completes user registration.

9.3.4 Registered Low Risk User (Risk Score 500 or Below)

A registered user logging in with a low risk situation is challenged with KBA.

1. "Frank" logs in to OAAM Server at 1:00 pm.

2. He does not have to register, so he presses Skip on the Registration page.

3. "Phil" logs in to OAAM Server with the same device as "Frank" at 2:00 pm.

4. He does not have to register, so he presses Skip on the Registration page.

5. "Stanley" logs in to OAAM Server with the same device at 3:00 pm.

6. "Stanley" is challenged because four users are logging in from the same device within 8 hours. The risk score is 500 (Rule Score is 1000, Weight is 100, Scoring Engine is Average), causing a KBA challenge.

9.3.5 Unregistered High Risk User (Risk Score Above 500)

A high risk login by an unregistered user is not be permitted to register.

1. High risk user, "Henry," logs in to OAAM Server with an invalid password four times.

2. High risk user, "Henry," logs in to OAAM Server with the correct password.

3. The user is locked since the risk score is 600 because of the invalid login attempts and the user is not registered.

9.3.6 Registered High Risk User (Risk Score Above 500)

A registered user logs in under a high risk situation and an OTP challenge to occur.

1. "Stanley" logs in to OAAM Server with the correct password.

2. He is OTP (SMS) challenged since his risk score is up to 600 because of the invalid login attempts.

9.3.7 Register High Risk Lockout

A user who has failed too many challenges can have their failure attempts reset by customer service.

In this scenario, a user is locked out by failing to correctly answer a challenge. The CSR must unlock the user, allowing him to log in. The user logs in and is challenged again.

1. "Stanley" logs in to OAAM Server with the correct password

2. He is OTP (SMS) challenged and types in an incorrect challenge value three times.

3. He is asked to answer KBA challenge.

4. He incorrectly answers KBA three times.

5. He is blocked.

6. He attempts to log in again but remains blocked.

7. The CSR who has logged in to OAAM Admin with CSR privileges, creates a case for "Stanley."

8. She unlocks OTP for him.

9. "Stanley" logs in to OAAM Server with the correct password.

10. He is challenged via OTP.

9.3.8 High Risk Exclusion

If a user is unable to use OTP, he can be added to an exclusion group to prevent the high risk challenge from occurring.

1. The Security Administrator logs in to OAAM Admin.

2. He adds "Stanley" to the "High Risk Exclusion" user group.

3. He modifies the OAAM Challenge Policy "Check for High Risk Score" rule to use "High Risk Exclusion" as the Excluded User Group in Pre-Conditions.

4. "Stanley" logs in to OAAM Server.

5. He is KBA challenged instead of OTP challenged even though he has a high risk score.

9.3.9 OTP Challenge with Multi-Bucket Patterns

"User: IP" is a multi-bucket pattern that creates a bucket for each IP address used by a user. It enables evaluations such as the following: if Jen falls into an IP address bucket that is less than 30% of all application users falling into that bucket, then OTP challenge her.

1. The Security Administrator logs in to OAAM Admin.

2. He creates a multi-bucket pattern for the member type "user" with an operator, "For each" and attribute "IP."

3. He confirms a policy which contains a rule with the following conditions- Has this user logged in at least twice in the last 3 months, Compare User Entity with all entities in picture (30%), and has this user OTP registered.

4. Jen logs in the Access Manager Server

5. She performs OTP registration

6. She logs in 2 more times from the same IP address.

7. For her 4th login, she logs in from a different IP address.

8. The rule triggers.

9. At a different IP address, she logs in again.

10. The rule triggers again.