Security vs. usability: Pros and cons of risk-based authentication

Introduction

Risk-based authentication (RBA) has to become part of the enterprise lexicon for a good reason. The authentication measures used to protect access to resources are at risk, and, in turn, those resources are also at risk. 

Mega data breaches keep on happening. The latest, at the time of writing, is the Cit0Day breach affecting 23,000 hacked databases containing around 13 billion data records, including email addresses and passwords. Couple the mega breaches with credential-stuffing attacks, of which there were 100 billion between July 2018 and June 2020, and you have a major problem with authentication.

A possible ray of hope in creating usable and secure access is to use a risk-based approach to access control. A 2020 report, “Usability and Security Perceptions of Risk-based Authentication”, attempts to tweeze out the issues of credential use within the complex online systems and services we use today.

Risk-based authentication: Is there such a thing as usable security?

Let’s face it: logging into a service or app is a pain. We all have myriad accounts and most require, often complex, passwords. Password security is known to be less than ideal; phishing makes passwords, even robust ones, extremely vulnerable. But when Google tried to implement two-factor authentication (2FA) less than 10% of active Google users had turned on the facility by the end of 2018. Why is this? 

It is general knowledge that passwords are insecure. But using a second factor can be a burden on the user, the system designer and the administrator. The usability versus security issue is neatly encapsulated in Google’s attempt to strengthen login security using 2FA.

Risk-based authentication (RBA) is an alternative way of dealing with the security-versus-usability dilemma. In a nutshell, RBA systems use rules to determine the outcome of a login. 

For example, let’s say there are three risk levels: low, medium and high. If a user performs a login that falls under a low level of risk, then login occurs without issue. If the user is at a high level of risk during login, an additional authentication option would be required before allowing access. The rules and levels of risk are usually configurable and represent a spectrum of risk.

The “Usability and Security Perceptions of Risk-Based Authentication” study explores the dilemma of authentication usability vs. security and explores how a risk-based approach can be used to improve matters. 

Risk-based authentication report overview

The study was conducted using a series of questions and a semi-structured interview, on the user experience of online site access; the website was specifically set up for the study. The site reflected many of the features and functions of typical online sharing and collaboration portals. So, personal data, files and images could be uploaded and shared.

During a registration for an online account, the cohort of testers were assigned one of four conditions: 

1. 2FA: The participant was prompted for additional authentication after each successful password entry. More specifically, the participant was requested to enter a security code that was sent to the participant’s email address.
2. RBA-DEVICE (RBA-DEV): The participant was prompted for re-authentication via email, as in the 2FA condition, but only in cases where the device used for logging in was never used before by the user.
3. RBA-LOCATION (RBA-LOC): The participant was prompted for re-authentication via email, as in the 2FA condition, but only in cases where the device’s location was never seen before for this user.
4. PASSWORD-ONLY (PW-ONLY): The participant was not prompted for any additional authentication at all.

A series of seven tasks were used. Each reflected real-world work tasks, and the tasks could encompass changes to the conditions of the login to initiate a risk-based response. The survey and interview questions, as well as videoed evidence, were used to ascertain the user experience and interaction with the RBA approaches offered across the cohort. 

It is worth noting that mitigation of bias was a consideration across the study.

Pros and cons of risk-based authentication

The results of the study were split into two areas: usability and security.

Authentication and usability

Finding 1: “… the participants perceived RBA significantly less annoying than 2FA”

This particular finding is interesting as it shows clearly the issues around usability and 2FA. Participants rated 2FA as “significantly more cumbersome to use and significantly more unnecessarily complex compared to PW-ONLY and both RBA conditions.”

This fits in with other push backs experienced on the use of 2FA in real-world scenarios, e.g., the Google attempt at offering 2FA to email users.

Finding 2: “On both RBA and 2FA conditions, the results showed a general higher acceptance for email than for mobile phone number or authenticator app” 

One of the issues with a second factor is the inconvenience. However, the context of a transaction changes people's minds. When applied to high-value/sensitive transactions such as online banking, participants had a high level of acceptance in using a mobile phone number or installing an authenticator app.

Finding 3: “The large majority of all participants understood the re-authentication.”

The participants in the study understood the concept of a change in behavior, in this case, location or device, resulting in a re-authentication. This is good news, as user acceptance is key in ensuring continued interaction with customers and a business. Acceptance is also tied to relationship building and trust, both needed for good customer relations.

Authentication and security

Finding 4: “… the security perception of RBA, if triggered, is significantly higher than password-only authentication and comparable to 2FA”

Participants felt at least as secure as 2FA when RBA was initiated. This was because of the link to out-of-band methods of double-checking the access; users assuming that to get to the next level of access they would need access to a personal device or email. One participant stated: “I assume that [strangers] have no access to devices on which I have already confirmed my identity. That’s why I think the security is quite good”.

Finding 5: “… participants felt significantly more protected with RBA and 2FA than with password-only authentication.”

The feeling of being protected was achieved with RBA … but only if it was a visible check. The system must display an online notice or similar, so that users can see the action and why it is being taken.

Finding 6: “Online banking and online shopping involves sensitive financial data. For this reason, participants had higher demands on security than on usability in this context …”

This outcome fits in with Finding 2. In other words, context is important in developing the underlying rules and levels of security and behavior of a system. If a transaction is of low value and does not involve sensitive data, the RBA or 2FA rules should reflect this and vice versa.

From risk-based authentication to usable security

The study shows several clear findings:

• Context is key: Users will modify expectations and behavior depending on perceived need, e.g., high-value transactions need higher levels of security.
• Messaging must be clear: If you tell a user what is happening, they are more likely to accept a security action, even if it is annoying.
• Easier options rule: If you can make the RBA mechanism simpler, do so. Participants preferred the ease of use of email rather than installing/opening up an authenticator app. However, context affects this view, and the higher value a transaction, the more likely the acceptance of a third-party authenticator app.

It was also noteworthy that when email was used, if the login and RBA email response were performed on a smartphone, the user was more accepting and found the process easier.

One area that stood out as a difficult to resolve issue was called the “The Deadlock Problem”. For example, participants being unable to access an email to perform the RBA requirement. Suggested ways around this include offering alternative options to go through an RBA process or to create “green rooms” where users themselves inform the system of a change in circumstances, e.g., inform on a location change to suppress an RBA request.

Conclusion

The report mentions that by 2018, only five popular online services had implemented RBA. However, the researchers are hopeful that NIST digital identity guidelines will result in wider usage.

This report is very useful for system designers that need to add in access control measures. By understanding the drivers and pushbacks in the use of authentication, from both a usability and security perspective, you can build better systems. Ultimately, it all comes down to ease of use and choice in security measures. 

When Google was asked about why they did not enforce 2FA back in 2018, they replied that it was because of the impact on usability. The UX of security is every bit as important as the UX of web and app design. By taking account of user choice and understanding how to use risk to determine requirements, the usability and security balancing act can be achieved.

Sources

Inside the Cit0Day Breach Collection, Troy Hunt

Akamai Report Reveals Broad, Persistent Cyber Attacks Targeting Video Game Players And Companies, Akamai

Digital Identity Guidelines, NIST