MFA Post 6: Push Notifications or Approval Mode
The factors we have discussed so far, SMS and OTP have some interesting disadvantages. SMS is not delivered securely and can be intercepted. OTP requires a certain amount of cognitive load that could hamper adoption. Study after study has shown that ease of use is a crucial factor in adoption. A study by Weir et al in 2009 showed that users deliberately chose a less secure solution that was considered more usable). (“User Perceptions of Security, Convenience and Usability for Ebanking Authentication Tokens”, Computers & Security, February 2009, https://www.researchgate.net/publication/222818183_User_perceptions_of_security_convenience_and_usability_for_ebanking_authentication_tokens)
In a push (pun intended) to make MFA consumable and easier to use, a relatively novel concept was invented: push notifications or approval mode. In this system, after the user enters a username and password, or in some implementations, just a username, they receive a prompt to approve the authentication on their mobile phone.
The user selects “Yes” or “No” as appropriate. If the user selects Yes a signal is returned from the phone to the IdP to proceed and authenticate the user.
This provides security by first enrolling the application. The user sets it up by electing to use Push notifications for login, downloading the app, and then performing some form of enrollment step, typically by logging into the app and perhaps scanning a code similar to how TOTP works. The app is now “trusted” to approve authentication and the possession proof is composed of the user having the app in their possession.
There are numerous commercial implementations of this in single-sign on systems such as Duo, Ping Identity, and Okta. For consumer implementations, Authy supports a number of popular services, and Microsoft Authenticator and the Google app, respectively, implement push notifications for login approval for their respective services, for both commercial and consumer versions. Apple uses push notifications as part of its 2-factor authentication solution for iCloud
A special note here is important. Both Microsoft and Apple actually use a hybrid approach. We have already seen Microsoft’s solution in a previous post, where you have to pick a specific button out of three to approve the login attempt.
Apple's mechanism is slightly different and a hybrid between approval mode and TOTP. Apple first shows you the approval prompt.
Only after you click "Allow" do you get a TOTP code. The TOTP code is delivered to one of your devices over a proprietary protocol rather than SMS:
You have to enter this code in addition to the approval prompt. This technically means that the system uses more than one factor, i.e. it is in and of itself a 2-factor authentication system. There is the possession proof that you effect by selecting the “Yes” option in the prompt, but then there is the second proof where you have to pick the right “Yes” option, or enter the code into the web page, which constitutes having access to the system that is actually doing the authentication. This implementation increases the phishing resistance of this solution quite a bit. In fact, under the National Institute of Standards and Technology (NIST) Digital Identity guidelines, NIST 800-63-3, which I will discuss in a later article, this might be considered a multi-factor authenticator, not a single-factor authenticator.
The most prominent advantage of Push notifications is simplicity. It is designed to make 2-factor authentication usable by everyone. Some implementations, like the one from Apple that we saw above, even largely do away with the setup step. Once you turn on 2-Factor Authentication, most of your approved devices are suddenly turned into trusted devices that you can use to approve a login.
Most phishing attacks today may not take 2FA into account, but the ones that do typically expect that users use TOTP or SMS, as those are the most common mechanisms in use by consumers. Some of the phishing toolkits, including ones meant to be used by defenders in testing, make such assumptions (c.f. https://blog.malwarebytes.com/cybercrime/2019/01/two-factor-authentication-defeated-spotlight-2fas-latest-challenge).
Push notifications would defeat those types of tools. However, and this is a very big however, this depends on the user noticing that they are on a phishing page after they enter their username and password but before they click OK on the push notification. If the push notification includes some context, such as where the login is coming from, it is possible the user would notice that and think twice before clicking. However, geolocation is tricky and made inaccurate by proxies, gateways, and ISPs, all the time. Yesterday, I was sitting in my living room all day and the notifications told me I was in at three different places, thousands of miles apart. Those were legitimate requests. I don’t think, but do not know for certain, that most users really use the location information in decision making because it is so often wrong.
Push notifications are great because they are simple. However, simplicity is not risk free. Push notifications are not as phishing resistant as some alternatives, largely because they require users to make a security decision without having much data to go on when making that decision. For several decades security practitioners have joked that asking end-users to make a security choice is like asking “Do you really wish to see the naked dancing pigs, or do you want me to keep asking you until you say yes?” The reality, unfortunately, is that many users will simply click “Yes” regardless of whether they initiated the prompt or not. In fact, anecdotal evidence indicates they will click “Yes” no matter what they are doing at the time, even if they are nowhere near a computer and are doing nothing that could even remotely be considered logging into something. I have heard stories of users clicking "Yes" while they are at the grocery store. This means that if an attacker can guess, or phish, the password of a user, there is a reasonable chance they can get the user to click the “Yes” button. Like I have said before, any multi-factor authentication is far better than no multi-factor authentication, but while push notifications decrease the success rate for phishing, it does not eliminate it.
Solutions that combine approval mode with an additional factor do lower the phishing risk, typically while maintaining the ease-of-use of push notifications. In Microsoft’s case, unless the attacker is acting as a man-in-the-middle (MITM), it’s cut in ⅓. In Apple’s case, the attacker actually has to be able to get the code from the end-user, either as a MITM or by asking the user.
The usability advantage is deserving of more study, however. An interesting study into various MFA options conducted as part of a master’s thesis at BYU discovered that, while the time to authenticate using push notifications was the second lowest, users considered push notifications less usable than TOTP (https://scholarsarchive.byu.edu/cgi/viewcontent.cgi?article=7869&context=etd). This is somewhat surprising, considering the entire point of Push notifications is simplicity. Some push notification systems, such as Okta, have Apple Watch apps and you can approve the notification on the watch instead of the phone. I would expect this to raise the usability score.
Push notifications do improve security - all MFA options do. However, they have certain weaknesses, not inherent in the technology itself but rather in the people who use them. Push notifications require people to make security decisions that they, sadly, are not very well equipped to make. For that reason, while they are sound technologically, I believe push notifications are less secure than TOTP. While they are billed as more convenient, that may also not be true in all scenarios. For this reason, I would recommend using TOTP over Push notifications, if the choice is between the two. TOTP is more secure in practice, and may perform similarly from an ease-of-use perspective.