Safety of Push-Based MFA Being Shredded by End Users
I wrote a book on hacking multifactor authentication (https://www.amazon.com/Hacking-Multifactor-Authentication-Roger-Grimes/dp/1119650798). In writing it, I reviewed over 150 different MFA solutions. Doing so exposed me to the good and the bad of MFA. I even taught a webinar on what I learned (https://info.knowbe4.com/hacking-150-mfa-products).
My book (https://www.amazon.com/Hacking-Multifactor-Authentication-Roger-Grimes/dp/1119650798) cover image is below.
In my writings and presentations on MFA, I frequently talk about how pushed-based phone MFA is one of my favorite types of MFA. With push-based MFA, when you are logging into a website, a related service “pushes” a login approval message to you. You click on “Approve”, “Yes”, or something like that to get logged in. Or choose the other option to prevent the login. It is pretty easy to use and fairly secure. See an example push-based approval notice below.
Push-based authentication is used by all sorts of popular vendors, like Google (shown above), Amazon and Microsoft. Yes, it can be hacked and bypassed like anything else, but out of all the different types of authentication options that are available, I put them in the upper third of what I like and trust. I am not alone. Push-based authentication is growing in popularity while many other types of MFA (even far more secure methods) are struggling to survive.
Houston, We Have a Problem
But lately, what I am hearing is having me question how secure pushed-based MFA solutions really are. Not from a technical standpoint, although they certainly can be hacked technically, but mainly from the human element perspective. What I am hearing is anecdotal, but if true across the wide population is pretty disturbing. I cannot tell if is a user issue or something that needs to be pushed (excuse the pun) higher up the chain and is really a problem of education, communication and management. If it’s widespread, it’s the latter.
What I am hearing is how often end users are approving push-based notification messages when they are not actually logging on! They are approving malicious logins…many times when the user is not anywhere near their computer. They are home, watching a TV program, eating dinner or whatever, when a push-based approval notice comes in – and they approve it. The pushed-based notification may even tell them the login is coming from another country. They don’t care. They just click on Approve. Apparently, this is a not an uncommon problem.
The first time I heard of this was from a Midwest CEO. His organization had been hit by ransomware to the tune of $10M. Operationally, they were still recovering nearly a year later. And, embarrassingly, his most trusted VP was who let them in. It turns out that the VP had approved over 10 different push-based messages for logins that he was not involved in. When the VP was asked why he approved logins for logins he was not actually doing, his response was, “They (IT) told me that I needed to click on Approve when the message appeared!”
And there you have it in a nutshell. The VP did not understand the importance (“the WHY”) it was so important to ONLY approve logins that they themselves were participating in. Perhaps they were told the correct instructions. But I bet there is a good chance that IT, when implementing the new push-based MFA, instructed them as to what they needed to do to successfully log in (to get users up and working), but failed to mention or highlight what they needed to do when they were not logging in if the same approval message arrived. I bet IT assumed that anyone would naturally understand that it also meant not approving unexpected, unexplained logins. Did the end user get trained as to what to do when an unexpected login arrived? Were they told to click “Deny” and to contact IT Help Desk to report the active intrusion?
领英推荐
Or was the person told the correct instructions for both approving and denying and it just did not take? We all have busy lives. We all have too much to do. Perhaps the importance of the last part of the instructions just did not sink in. We can think we hear and not really hear. My wife will tell you that is me every day.
So, I am sharing this story with another IT security professional I ran into on a plane on the way home from my consulting gig, and he says, “My IT Director approved over 20 malicious logins the same way!” They were also hit by ransomware, but their cybersecurity insurance covered them. It got me wondering. I started calling and discussing this with different penetration testing and red teams, and all of them told me how often users are approving their “malicious” login attempts.
One pen testing team leader told me, “When we hear that a client has push-based notifications, we literally start laughing. You cannot help it. We know what we are going to do and how we are going to get in. I would say three out of five people we test just approve our logins. It is like hitting all the buttons on an apartment building buzzer console to see which random people will buzz you through the front locked security door because someone is always waiting for someone. There are always people who will just click “Yes” because they have been trained to click on “Yes” and the whole reason why they should click on “Yes” versus “No” has become a forgotten distraction. We are literally training them to approve everything. It makes our jobs easy.” Most of the penetration teams say that it is so easy to break in using push-based MFA, that they would not recommend it to anyone.
To be clear, this is not a technical problem with the type of MFA solution. It is still MFA. In order to work, the attacker still usually (depending on the second factor) has to discover the user’s login name and password. Using push-based MFA is probably still better than only using a login name and password combination. Of course, the problem becomes a lot worse if the push-based "MFA" is really single factor authentication (1FA). Many of the push-based authentication methods require ONLY that the user approve the logon notice and don't require a second factor. In those cases, it's literally asking for your company to be compromised. A logon name/password combination would likely be more secure.
Either way, it is obvious that push-based MFA (and 1FA) is failing a whole lot of organizations. I have been writing about the problem of overreliance of MFA on preventing cybercrime for a few years now, including here recently: https://blog.knowbe4.com/cyber-insurance-industry-wrongly-hedging-its-bets-on-mfa. I think anyone buying all the “MFA will solve 99% of your cybersecurity issues” declarations are in for a rude awakening. But there is a fairly easy solution.
Education is the Solution
A lot of the problem with MFA is that the deployers do not do enough education, to themselves and to end users. They do not understand all of the ways that MFA can be hacked, bypassed and the end user manipulated. Too many organizations and industries think that simply using MFA makes them significantly less likely to be hacked and it just is not true. MFA does significantly diminish the risk of some forms of authentication hacking, but not even all forms of authentication hacking, much less all hacking (e.g., unpatched software, social engineering, man-in-the-middle attacks, etc.). You should use MFA where you can in order to protect valuable data, but it should always come with and be deployed with good education.
Buyers, implementers, administrators and senior management need to understand what MFA can and cannot prevent. Anyone thinking that MFA prevents almost all hacking needs to be corrected. It is a common misunderstanding and one that can be fatal to an organization’s computer security risk evaluation. Sysadmins need to understand how the MFA solutions they use can be hacked, bypassed and what the most likely “in-the-wild” attacks are. Implementers should make sure that all users are instructed on how to appropriately use their MFA (including when to say “Deny”), what the common attack methods are against their type of MFA and how to defend against those attacks.
We are constantly telling our end users about how to use passwords safely. We tell them to use unique passwords on every website and service. We tell them not to use easily guessable passwords. We tell them to use some non-alphabetic characters in their passwords. We tell them to periodically change their passwords. We need to do similar things when we deploy MFA. Do not just teach a user how to successfully use their MFA. Teach them how to use it AND how it can be used against them. Just because you are using MFA does not mean there are not instructions to follow and things to watch out for.
The people who are falling for these malicious push-based MFA approvals are not idiots. They are CEOs, doctors, lawyers and even IT people. They are not dumb. They just did not get the complete education about how and why to use their MFA, at least with enough focus on what not to do.
No matter what MFA solution you use, make sure you come up with a good and thorough education program to go along with it. Do not assume that everyone knows how to use it and what to look out for. A little education goes a long way.?
Information Security and Compliance Manager
3 年“…and is really a problem of education, communication and management”. Hit the nail on the head here. I’ve been pushing heavily for conditional MFA wherever possible, because, as we learned with Windows User Account Control, most people don’t care about security popups, so they just click whatever it takes to get back to what they were trying to do. Designing a security program that is ironclad but irritating to users is a guaranteed way to have disengaged users who are easier targets!
Secure,Award Winning Electronic Recycling. NO CHARGE! Try us. You will be thrilled. WBENC CERTIFED
3 年No. Not me.
Revenue and data at risk online? ?? | Cybersecurity Advocate: Building Human Firewall ???
3 年Marko Gulan, Tomislav Poljak zanimljivo zapa?anje.
Instructor at Herzing College
3 年Very interesting, Roger. Yet another human vulnerability. Do we have to keep adding technological solutions while disregarding the human factor?
Snr Information Security Engineer at KnowBe4 |B.Sc| Sec+ | CySA+
3 年Is it really even hacking if they were, while unwittingly, let right in? I covered this same example during our last workshop.