What Is Risk-Based Authentication?

As businesses onboard more mobile and remote employees, partners, contractors, and other external users, the volume of people needing access to critical systems and data grows exponentially. And while this increased connectivity provides tremendous operational and productivity benefits, it also creates new attack vectors for intruders and cybercriminals.

CSOs, CIOs, CTOs, and other security and IT leaders have a responsibility to protect their organization's data, systems, and IP assets. It’s important to leverage the right technologies to make system access as safe and secure as it is seamless and affordable. Password-based authentication methods must be replaced or augmented with additional layers of security that are easy to deploy and frictionless for the end user.

Risk-based authentication (RBA) meets both criteria and should be considered by organizations of all sizes. This technology protects against sophisticated security breaches and hackers, while reducing issues that result from a dependence on passwords and one-size-fits-all authentication strategies.

What Is Risk-Based Authentication?

RBA is a form of strong authentication that calculates a risk score for any given access attempt in real time, based on a predefined set of rules. Users are then presented with authentication options appropriate to that risk level.   

While risk-based authentication can be static or adaptive, the focus of this post is static RBA.

Creating Risk Scores from a Blend of Contextual Factors

Risk scores are the key measure for RBA and are used to determine risk level. In turn, risk levels measure whether a login attempt is legitimate or likely fraudulent.  

Risk levels are compared to a threshold score that is established as a policy in your authentication or identity and access management (IAM) platform. This comparison determines the authentication method needed for the login attempt.  

Risk scores are based on a number of contextual factors related to the access attempt, including:

• Login Device: Is this a registered or known device? Is there an associated fingerprint that can verify the device?
• IP Reputation: Is this a known or suspect IP address or subnet associated with bad actors?
• User Identity Details: Is the user’s information being presented the same as the information stored in the directory or user store?
• Geolocation: Is the user’s current geographic location known to be good or bad? Are there certain locations to which you simply need to block access or should access only be granted if at a specific facility?
• Geovelocity: Does the user's location and time of login make sense given the time and location of the last login attempt? I.e., you can’t log in in San Francisco at 1:00 PM PST if you just logged in from Boston at 2:30 PM EST.

Risk scores also can and should include other actors, such as:

• Personal Characteristics: Time with company, role or job levels, history of security incidents and certifications, granted entitlements, etc. I.e., if a user fails to pass an internal security certification exam or falls prey to an internal phishing test, the user is automatically required to “step up” to two-factor authentication.
• Application or Data Sensitivity: How critical or sensitive is the target system or data being accessed? Do certain systems mandate a second or third form of authentication? For example, an intern should not have access to any financial systems.
• Number of Attempts: Fail three times and your account is locked until you call support.

To be clear, a risk score should be a combination of many contextual, individual, and system factors, as any one factor on its own can and will be beaten by an attacker.

What Authentication Techniques Are a Best Fit for Risk-Based Authentication?

Most RBA implementations use challenge and response questions—an authentication protocol in which one party presents a question (challenge) and another party must provide a valid answer (response)—as the second factor after submitting a username and password. While cost-effective and easy to implement, we recommend only using this method as a fallback when internet or WiFi are unavailable. Challenge and response authentication is simply not as secure as other smartphone, token, and smart card-based authentication techniques. This is because breaking the authentication method only requires a little social engineering, rather than actual technical hacking.

Instead of challenge and response authentication, we recommend choosing from these other strong authentication techniques:

• Push authentication
• One Time Password (OTP) and Time-Based One Time Password (TOTP) authentication
• FIDO U2F tokens
• Smartcards with PKI—particularly if cards are already in use for facility access or other purposes
• Fingerprint biometrics

Smartphone-based options, such as push authentication and one time passwords, are a particularly good fit for Risk-Based Authentication. This is because they deliver a multi-factor verification experience that is largely transparent to the end user.  

For example, a user logs into the RapidIdentity Portal with a username (something you know).

Next, the user is asked to approve or deny a push notification on the user’s smartphone (something you have)—either in addition to or in place of a password (something you know). Now, what you may not have even realized is that a third authentication event happened when the user logged into the smartphone with a touch ID and verified him or herself as the owner (something you are).

And there you have it: three factors. However, to the user, it just seemed like one—the push approval.  This is an example of a highly secure, yet non-disruptive, experience for end users.

Myth: Risk-Based Authentication Is Only for Large Companies

In reality, RBA should be considered by companies of all sizes. RBA is:

• Quick and easy to configure and install.  
• Very cost-effective -  Organizations can leverage existing authentication solutions and user-owned smartphones.
• Frictionless - Most access requests fall below the defined risk thresholds. So, only a fraction of requests require additional authentication.    
• Easy to manage and maintain - As new threats and risk factors are identified, adding them to your scoring and comparison processes is simple.

We also recommend deploying a secure single-sign-on portal that consolidates all external applications. In this scenario, users must first authenticate to log into the portal to gain access to applications. Another alternative is through a federation approach, in which all external-facing applications point toward a federation server, which is a software component that provides users with single-sign-on access to systems and applications located across organizational boundaries. When attempting to log into applications in this scenario, users are redirected to a shared server that can perform risk-based analytics to grant access.

Block Unauthorized Access and Data Theft with RBA

With today’s widely available hacking tools and cheap computing power, persistent and sophisticated intruders can get past even the most fortified perimeters—often simply by guessing or breaking a password. However, by deploying risk-based authentication, you can protect your systems and data by making those stolen passwords useless.  

Stay tuned for a future blog on adaptive authentication, which takes RBA to the next level with behavioral analysis and account adaptation and learning.