Risk Based Authentication

Skip to end of metadata
Go to start of metadata

Overview

Risk Based Authentication (RBA) is an added layer of account security which calculates the level of risk associated with a given login attempt and presents users with authentication challenges according to that risk level. RBA includes two types of rules for determining the risk level and its outcomes: global rules, which apply to all login attempts in your site (or site groups), and account rule-sets, which apply to individual accounts (used to ensure a more secure authentication for accounts with stronger permissions, such as site admins and other employees). Gigya provides several rules of each type out of the box. 

Components

Risk Factors

Any of the following events can trigger a requirement for a higher level of authentication: 

  • Failure to login after a specified number of attempts, from a specific account or IP address.
  • New device used for login.
  • First login from a different country.

Authentication Levels

Authentication levels are associated with each authentication method by their degree of security. A higher authentication level means a higher level of trust. When defining rules, assign a higher required authentication level for more suspicious behavior. For example, you can define that when a user tries to log in from a new country, they have to pass a two-factor authentication with a level of 20, meaning a one-time password (OTP) for the second authentication step has to be sent to the user's phone, whereas activity that is perceived as less suspicious, such as a device change, might only require an authentication level of 10, meaning users can verify with an OTP sent to their email. 

Authentication MethodAuthentication Level
Email10
Phone20

Note that a new registration automatically receives an authentication level of 10.

Security Methods

The following security methods can be applied to a login attempt using RBA: 

  • CAPTCHA : Requires that the user successfully pass a CAPTCHA challenge, thereby preventing account hacks via automated login attempts
  • Two-Factor Authentication (TFA): Is a security process in which the user provides two means of identification; the first is the password when initially logging in and the second is an authentication code the user receives via text or voice message to their mobile device to complete the login process. 
  • Lockout: Disables the ability for the user or IP address to successfully login to an account for the specified length of time. 

Rules

RBA includes two types of rules for determining the risk level and its outcomes:

  • Global Rules: Apply to all login attempts in a site (or site group). In the RBA Policy object these are defined in the commonRules array. 
  • Account Rule-Sets: Apply to individual accounts. Usually used to ensure a more secure authentication for accounts with stronger permissions, such as site admins and other employees. In the RBA Policy object these are defined in the ruleSets array. 

Multi-Sites and SSO

RBA can be used in a nuanced way in a multi-site scenario. Capabilities include: 

  • Rules are configured for the parent site, and apply throughout the site group. For example, if you set a risk factor of 3 failed logins for the parent site, and a user has failed two consecutive logins on child-site A, the risk factor will be triggered if the user immediately attempts and fails to login to child-site B. 
  • You can use the apiKey root factor to set up different rules per different API keys. 

Network Protected Identity (NPI)

Network Protected Identity is a component of RBA that capitalizes on the data gleaned from the login activity of ~1.2 billion identities stored at Gigya, to benefit users of RBA and enhance overall security. An email or IP address which displays suspicious behavior (hack attempts) is automatically flagged, so that you can define a low threshold of failed login attempts from these sources, and automatically lock out the account, force it to pass a CAPTCHA challenge, etc. The relevant values are: 

  • global_IP
  • global_email

For more information, see Accounts RBA Policy Object.

  • NPI does not store any user data. The data it stores pertains only to suspicious account activity.
  • NPI does not in any way share user data.

Configuration

Rules

To apply a new global rule: 

  1. Go to the RBA page in Gigya's Console.
  2. Under Global Rules, click Add Rule
  3. You can base the new rule on the existing templates, or create a custom rule. A template-based rule can be edited in the next step. 
  4. In the Add Global Rule window, the risk factor is defined under Root Factor, and the action taken if that factor is triggered, under Action. You can edit the following: 
    • Description
    • Status: can be switched on or off (this can be done from the RBA dashboard as well)
    • Root Factor: you can change the type, scope, threshold, resetInterval and any other parameters that appear. For more information consult the Accounts RBA Policy Object, under the commonRules array. 
    • Action: you can change the type, scope,duration and authLevel, as relevant to the chosen root factor. For more information consult the Accounts RBA Policy Object, under the commonRules array.
  5. Click Save Settings

When setting custom Global Rules, only enter the actual value of the action/rootFactor property:

Correct Action field:

{
  "type": "TFA",
  "authLevel": 10
}

Correct Root Factor field:

{
  "type": "device",
  "authLevel": 10,
  "expirationPeriod": 300
}

Incorrect Action/Root Factor Fields:

"action": {
     "type": "TFA",
     "authLevel": 10
}
 
 
"rootFactor": {
     "type": "device",
     "authLevel": 10,
     "expirationPeriod": 2592000
}

 

Account Rule-Sets

Create Rule-Set 

  1. Go to the RBA page in Gigya's Console.
  2. Under Global Rules, click Add Rule-Set
  3. You can base the new rule on the existing templates, or create a custom rule. A template-based rule can be edited in the next step. 
  4. In the Add Rule-Set window, you can edit the following: 
    • ID: the unique ID of this rule. The ID must be unique and not start with an underscore _ . 
    • Status: can be switched on or off (this can be done from the RBA dashboard as well)
    • Rules: edit the JSON object according to the Accounts RBA Policy Object documentation. Note the Policy Examples
    • Click Apply

Configure How the Rule-Set Applies

Rule-sets are applied to user accounts by passing the details in the rba parameter of accounts.setAccountInfo together with the UID to which the rule applies.

Rule-sets can apply to designated users, or can be made the default rule-set to apply to all users. In addition, you can give permissions to the admin and the end-user to override the rule-set. 

  • To apply one rule-set to all logins, select the rule set from the Default Account Rule-Set dropdown. In this case, the selected rule will apply to all users together with the global rules
  • To allow an admin, or an admin and the end-user, to override the applied rule-sets, select the relevant option under Account Rule-Set Override

 

Saving the RBA configuration uses the accounts.rba.setPolicy REST API to set the RBA policy, passing your Gigya API key and the RBA policy object as parameters.

Example

Say you have configured the following policy, which is defined globally (as common rules and not rule sets): 

  • Trigger a lockout after 5 failed logins from a user account
  • Trigger a CAPTCHA after changing a country
  • Trigger a phone TFA when logging in from a new device

    A device is determined by a cookie set in the user's browser, multiple browsers on the same platform/OS are considered as separate 'devices'. Deleting cookies will also cause logging in from the same browser to be treated as a new 'device'.

    • If you wanted to trigger TFA for every user on every login, you would accomplish this by creating a Common Rule for triggering TFA, you would set this rule to trigger on Device Change, and you would set the Device expirationPeriod to a very low integer, e.g., 10 seconds.
      Example:

      {
      // Permanent TFA
          "enabled": true,
          "description": "TFA for all users always",
          "action": {
              "type": "TFA",
              "authLevel": 20
          },
          "rootFactor": {
              "type": "device",
              "authLevel": 20, 
              "expirationPeriod": 300,                       
          }
      }

      For additional information on how TFA works, see Console Two-Factor Authentication.

The policy object looks like this: 

{
    "commonRules": [
        {
        // rule #1 - Lockout after 5 failed logins
            "enabled": true,
            "description": "Lockout",
            "action": {                
                "type": "lockout",
                "scope": [
                    "account"
                ],
                "duration": 43200
            },
            "rootFactor": {                
                "type": "failedLogins",
                "scope": [
                    "account","ip" //locks out both this account and the IP from which the attempts were made
                ],
                "threshold": 5,
                "resetInterval": 86400
            }
        }, 
		{
		// rule #2 - CAPTCHA after country change
            "enabled": true,
            "description": "CAPTCHA after country change",
            "action": {
                "type": "captcha",
                "scope": [
					"account"
				]
            },
            "rootFactor": {
                "type": "country",
                "scope":  [
					"account"
				],                
                "resetInterval": 3600
             }
        },
		{
		// rule #3 - Phone TFA from a new device
            "enabled": true,
            "description": "Phone TFA from new device",
            "action": {
                "type": "TFA",
                "scope":  [
					"account"
				]
            },
		  "rootFactor": {
                        "type": "device",
                        "authLevel": 20, 
						"expirationPeriod": 86400,                       
                    }
		}
    ],
}

 

As a result,

  • A user will see a lockout screen on their sixth login attempt
  • A user will be challenged by CAPTCHA after changing a country: 
  • A user will be required to enter a code from their phone when logging in via a new device:

For more examples, see RBA Policy object example.