Part 1: Usability Is Security
A Retrospective on Authentication, Authorization and Human Psychology in Cybersecurity
Authentication and authorization have changed over the years, and continue to do so. As the internet became a core part of communications, threats expanded from local to global, and from technological to psychological. Information security is still often dependent on computer passwords; a creation of the 1960s, as well as network perimeters; a distinction that becomes less relevant every year.
Attacks increasingly involve exploiting human psychology as much as technology. The security community had learned a lot from 50+ years of information security and human behavior. I’ll discuss how we're using human behavior to our advantage and how easier-to-use security results in better security.
What is Information Security?
Information security is a huge and varied field, but at its core, the overarching goal is making sure malicious actors don’t get access to places, data and systems they shouldn’t.
A common issue that the security community comes up against is that a security system or feature is difficult to use, or is actively resisted by the users the system is attempting to secure.
Authentication vs. Authorization
Two of the most important components in information security are authentication and authorization. These terms are occasionally used incorrectly or interchangeably, or combined under the generic term “auth.” A simple way to distinguish between them is the questions they each attempt to answer.
Authentication attempts to answer the question “who are you?” as accurately as it can. Passwords are an example of an authentication system. Multi-factor authentication methods such as security keys and time-based codes are used to increase the confidence of the authentication.
Authorization attempts to answer the question “should you have access to what you’re attempting to access?” Authorization systems are more varied than authentication systems, but a commonly used one is the permissions setting in apps like Dropbox, Google Drive, or OneDrive. There you can add collaborators via their email address. Collaborators can then access the shared files if and only if they have authenticated with that email address, and met all of the authentication system requirements (usually a password).
Usability is Security
Security features and techniques must be utilized to be effective. Human psychology is as much a part of this process as anything else, if not more so. Security as a goal is generally well regarded by people, but has a reputation (not unjustifiably) that more security means less usability. For systems and services to truly be secure, they must have good security features that lend themselves to being easily configured and used.
Historical Examples
There have been many attempts to solve security issues without truly considering human psychology as a response.
One such example is passwords. Passwords have long been compromised and intercepted by man-in-the-middle attacks. The impact of these security concerns was magnified by the fact that many users understandably reuse their password across multiple services. As of 2017, the average business user had 191 accounts that needed passwords! A virtual impossibility without reusing passwords or using a password management tool.
The security community began addressing password reuse by requiring passwords to be changed regularly so that if a password was compromised by an attacker, it would “only” be usable for a limited time. However, password expiration policies resulted in the (now well known) phenomenon of people using extremely predictable passwords. While this would prevent a permanent silent takeover of the account, it didn’t prevent data loss which made this an inadequate mitigation for many organizations.
Once this realization was widespread, services began implementing multi-factor authentication (MFA). This was better than regular password changes and solved the same problem even better. However, the old password policies were often retained unnecessarily.
Early MFA was often implemented with RSA SecurID tokens. This was an effective mitigation, but required purchasing of a physical hardware token. MFA was eventually made easily available to common consumer accounts through SMS and TOTP apps (such as Duo Mobile and Google Authenticator).
Universal 2nd Factor (U2F) was another great advancement in both usability and security. With the Yubikey nano and other U2F devices, all that was needed for MFA was a simple press of a security key plugged into your laptop. U2F has strong defenses against phishing and is one of the easiest to use, however, it still required purchasing a separate device, which made it rare among consumers.
When used in tandem with relaxed password rotation requirements, these resulted in huge improvements over the previous state of affairs. However, unless MFA was required for the account, it was rarely enabled by the user. In 2016, less than 10 percent of Google accounts used MFA.
The additional overhead of some MFA systems were a deterrent to them actually being used.
The mobile device world had a similar issue. Devices were often not being protected with a password or PIN because it prevented easy usage of the phone. People unlock their smartphones about 80 times per day on average. The additional friction that a screen lock added made their usage uncommon. In the case of iPhones, Apple added Touch ID and Face ID features but also added biometric configuration to the phone setup flow. Today, 89 percent of iPhone users have screen lock enabled.
Security technology has to be easy to use and hard to miss.
Lessons Learned
One of the takeaways from early information security is that users will be more likely to configure and enable security features that are easier to set up. This seems obvious, and perhaps it is, but there was a basic assumption that people would configure their security settings to the appropriate level - unfortunately, it turned out that this was rarely the case.
Some of the conclusions drawn in earlier years were that users didn’t care about their own security as they weren't enabling security features. Yet, they got angry when security breaches happened. Users expect their devices to protect them, as opposed to the devices simply having options for users to protect themselves with.
People consider security a given when they buy a device. They expect “secure” to be a feature of a product, as opposed to the availability of “security features.”
This affects the level of engagement developers can expect from users. When using the product, there is a base level of engagement that’s happening, but deviation from the normal operations will result in interaction without real engagement. But the security expectations of the user remain unchanged.
A good example of this is a reoccurring topic from mainstream journalists on how third party humans can read your Gmail. While true, this only happens after the user views and accepts a dialog authorizing said third party to “read, [emphasis added] send, delete and manage your email.”
Users were presented with a dialog explaining exactly what they were agreeing to and agreed to it. After clicking “approve” on a dialog, users were angry that the action explained on the dialog actually happened.
When a substantial amount of consumers misunderstand something, we as engineers need to reexamine how we communicate that information.
Recap
So, as a security and engineering community, we have a few high-level takeaways:
Users expect security without having to work for it, and they expect for that security to be effective regardless of how much of any configuration was actually completed. This is not due to laziness, but because it’s an expected feature of the product.
Users engage best with a relatively easy step during a period of already expected friction, e.g. setting up a new device.
During unexpected friction of a product (oAuth, permissions, etc.), user engagement will be lower than other times. User education and engagement is crucial at this time.
As we move forward in developing new security technologies, the security and engineering communities have taken these and many other lessons to heart. I’m extremely excited about the next generation of authentication and authorization technologies as making them easy and accessible has been a top priority of mine.
In the next post in this series, I’ll discuss how the security community is applying these lessons to the next generation of technologies, and how the foundations have been already laid out using the technology you likely have in your pocket!