We’ve all seen it – and most of us have done it, too. So many alerts, notifications, and pop-ups assault us every day that users are clicking yes just to get rid of them. The blanket term to describe this behavior is “acceptance fatigue”, and it has severe repercussions for identity management and security. How did we get to this point of acceptance fatigue and what can be done to stop it?
Let’s start with how we got here. In the early part of the century, websites, banks, subscription services, and many others began using alerts to inform users as to what was going on with their sites and accounts. First, it was email: anything you did online generated an email alert. Change your password? Email alert. Sign up for a new site? Email confirmation and then another email to alert you that the confirmation was received. Sign into your bank from a new machine? Email confirmation and alert. This went on ad infinitum. As unlimited text messaging plans became the norm for mobile phone users, email alerts turned into SMS alerts. You still got all those emails, but you also got text messages with the same information. As security concerns over website usage and account compromise rose, these simple alerts turned into requests for confirmation. Not only did you get an email, but it now contained a link you had to click to confirm the operation in question. Now you received emails with a link to confirm the operation, then another email to confirm that it was successful, and a text message at the same time.
With the widespread adoption of smartphones and tablets, these alerts and confirmation prompts changed from email and text messages into smartphone notifications. Initially, accepting these notifications required opening up the app and interacting with it; but over time – and with advances in how notifications are handled on the phones – you could accept the notification and even take action without opening the app at all. Today, you can approve a login request for many platforms just by acknowledging the alert on your Apple or Android device – right from the lock screen in many cases. This has lead directly to the acceptance fatigue phenomenon. Users are bombarded with notifications, emails, and alerts that they need to accept a login or other event. As a result, users are just clicking, swiping, or otherwise accepting these notifications and alerts without looking at what they are anymore.
This means that login and other alert acceptance has become a truly passive experience, which is dangerous when it comes to protecting sensitive information. Two-factor authentication becomes useless when one factor will always be accepted by the end-user – regardless of whether they initiated the login themselves or not. An attacker can initiate a login, and a user – dismissing the alert as not important – approves that login even when they’re not at their computer.
One method used to combat acceptance fatigue is One Time Passcodes (OTPs), either time-based and continuously rotating or generated on-demand by a push event. While this does solve the basic problem since the user must type the passcode into a browser window or login prompt; it brings with it a host of new problems. Users are human, and as such make typos and otherwise have issues transferring even the shortest of valid OTPs from their device into whatever is asking for them. This becomes even more of an issue when attempting to log in from a mobile device, where the passcode is in one app and the place to type it in is in another. Secondarily, instructions on what the code is for and how to use it via text message or app display may not be localized, leading to issues when the user doesn’t speak the same language as whatever is displaying the OTP and where to use it.
Another method is “link-to-accept” systems that require the user to click on a link to finalize a login process. This solves a couple of problems – mainly by requiring users to unlock or otherwise open their devices to click the link and removing the need to manually type an OTP from one window/device to another – but introduces some of its own problems in return. First, the links can be maliciously formed and sent fraudulently. This leads to acceptance fatigue where the user clicks on any link in an SMS – creating a situation where the security tool actually initiates an attack of its own as they are sent to fraudulent sites that trick them into entering sensitive information. Secondly, if the link in question is delivered via email, the underlying system – such as an email server or client – can be compromised. This allows an attacker to also get a copy of the authorization link, bypassing the user entirely.
So, how do we deal with acceptance fatigue and the problems created both by the phenomenon itself, and those caused by previous attempts to fix it? There are a few different ways to do this:
- Use methods that don’t lend themselves to creating the problem. For example, leverage tools that minimize the number of step-up login events so that users treat the alerts seriously since they’re not getting bombarded by them. Adaptive authentication methods that only challenge for multi-factor logins when there is a known level of risk are one way to do this.
- Use methods that are simple enough to not be overwhelming or error-prone. Things like symbol-to-accept (which require the user to match a symbol on their screen to one of several on their smart devices) are a great method for this. They’re not blocked by language barriers since only the shape and form need to be matched, not a word or other language-dependent factor. They also don’t require transferring data from one screen/app to another – just a tap in the app after the device has been unlocked and the app opened up.
- Require opening an app to accept the second factor. In other words, use methods that cannot be accepted from lock screens or otherwise from a still-locked device or machine. The user can open the app from a notification, but cannot accept the prompt directly from the notification itself. Paired with the requirement that devices have passcodes/biometric locks; this removes the ability of the user to simply accept everything without looking at/interacting with it.
- Use methods that check for device fraud. Disable using email as a method of second-factor delivery. Stop using knowledge-based questions as verification (since that info is generally available on social media). Requiring dumb or smartphones for secondary factors and leveraging tools that check for phone porting, IMEI cloning, and other commonly-used fraud systems can at least ensure that the user mindlessly accepting a verification alert is the actual user and not an impostor.
Combining these methods will dramatically reduce – if not eliminate – the ability of users to fall victim to acceptance fatigue. At the very least, they will keep bad actors from taking advantage of users who are stuck in acceptance fatigue behaviors. Reducing the number of alerts keeps users from being de-sensitized to them in the first place. Checking that the phone or device still belongs to the user stops attackers from accepting in user’s place. Not using methods that don’t require unlocking keeps users from just accepting without double-checking what is going on, and using symbols and other match-up systems for accepting the alert removes language barriers and prohibits the “click yes to everything” mentality. Added together, each progressive layer applied brings us closer and closer to defeating acceptance fatigue.
Users will always take the path of least resistance when it comes to secondary authentication factors. Removing the most error and fraud-prone methods, combined with making things easier for users overall, will go a long way to stopping the impact of acceptance fatigue in your organization.