Multi-factor auth fatigue is real – and it's why you may be in the headlines next The September cyberattack on ride-hailing service Uber began when a criminal bought the stolen credentials of a company contractor on the dark web. The miscreant then repeatedly tried to log into the contractor's Uber account, triggering the two-factor login approval request that the contractor initially denied, blocking …
"overwhelming the user with push notifications. The user may initially tap on the prompt saying it isn't them trying to sign in, but eventually they wear down from the spamming and accept it just to stop their phone going off."
Instead of repeatedly sending out such notifications, surely the system should lock the user out completely after X number of rejections, requiring the user to escalate and contact IT/Security to try to gain access, who would hopefully use other measures to verify the identity of the user or determine it was a potential hack attempt.
My client uses Duo, and when the 2FA request comes through, it shows where the request is coming from, so I know its something I'm doing.
On the other hand, since the article mentions potential inadvertent authentications... Occasionally if my phone is flat on the desk and I pick it up, it switches between landscape and portrait... And the approve button on one orientation is in the same place as reject on the other. Never been a problem but its a potential slip-up (though I'm not sure it is something that could be exploited)
Final thought... If someone is being spammed by requests they didn't generate, why not just ignore them? I'm sure they go away on their own after a while
"Instead of repeatedly sending out such notifications, surely the system should lock the user out completely after X number of rejections"
Yes, that's discussed in the piece lower down. It's an option. You may not want to use that option as it could lead to a DoS-like scenario against staff but you might instead consider setting a rate limit anyway.
I've made a note of that option higher up in case people don't make it to the end.
C.
The article is fairly lengthy and I didn't make it to the end. I steal a few work minutes here and there to read up a bit but after a fairly short while I start scanning over the rest of these articles. Maybe we need executive summaries (or software dev summaries).
>Instead of repeatedly sending out such notifications, surely the system should lock the user out completely after X number of rejections
In the first instance it should apply lockout rules to the originating device, before applying them more generally to the account.
So for example on some services the MFA tells me it is a new device attempting to access my account, so they clearly know which devices I habitually use for their service.
"surely the system should lock the user out completely after X number of rejections"
And the design fault with that is effectively denial of service. Some IT bod is working through the weekend on an upgrade, shipping are working through to clear a backlog or the chief beancounter is down to the wire for filing tax on Sunday night, and now they're locked out with no IT support available to fix the problem until Monday. Not every business has or can afford 247 IT support.
NOOOOOO.... because then you are into a physical DDoS attack where a large group of users all contact a small group of admins at the same time and overwhelm the system.
Just imagine if that happened to a country's banks when all the customers get locked out and have to get their account access reset.
I know of one country that's ripe for that scenario. No names.
I don't mind two factor auth but...
A lot of sites/apps default to text, don't offer an email option...can be a royal pain for me, since I use PC's.
On a positive note, the GVoice number I set up years ago has finally become of some use.
Discovered that text to that number also shows up in my gmail!
I do have a phone, I just rarely use/answer it.
There is. A push request is sent, and the MFA system knows the IP address it's coming from. The owner of the login says it's not them. Why not just block the IP address that sent the denied request? Or better yet, block the IP range? Or even better than that, you know where your employees are, just allow an MFA request from the IP you expect them on. If they have to sign in from elsewhere provide a means to authenticate the new IP, like call this number and verify it's you signing in and you need this IP to work X number of hours/days.
requiring the user to escalate and contact IT/Security to try to gain access
That may be fine when it's your work account – though I don't want to see how long it takes IT at some organizations to process such an issue, if there's even a way to alert them to it when you're locked out.
How does it work when you're locked out of Gmail? Or Amazon? What additional channel of authentication do you have with third-party service providers who just see you as a source of income?
>As with other forms of social engineering, educating employees about the threat is important.
Almost entirely nonsense. Educate your employees all you like but in an organisation of thousands or even tens of thousands of people people there's always going to be someone who fucks up. To illustrate this point my employer's security team recently ran an internal phishing campaign. It was good. Like, really, really good. I'm pretty damned competent when it comes to security, and I came *this* close to falling for it. Hundreds of people actually did. In an organisation of only a few thousand, highly-skilled, tech-savvy people who all dutifully comply with their security rules.
Which is why none of us were all that bothered when we were required to obtain YubiKeys, set a passcode and embrace Numbers Challenges from our SSO. If our two internal security guys can successfully phish us, then you can bet the suspiciously well funded definitely-not-Russians working out of Eastern Europe certainly can.
You defeat phishing and social engineering by picking MFA that can't be (reasonably) phished.
"Almost entirely nonsense"
Well, we said it's important but - as the article goes into - not the only thing to do. Education is good but systems in place to block, contain, and detect are also important. I've made that clearer for people in the piece.
Also, as we said, someone may impersonate your IT staff so rate limiting won't help here, but phishing education and other defenses might. Finally, MFA spam really does work. There's been loads of times where it's worked, so limiting attempts and what not isn't a given at orgs.
We just had a load of phishing attempts against us too by someone pretending to be our CEO. The attempts failed but we still did a round of internal messaging/education about it afterwards as well as reviewing defenses and operations to make sure everyone's on the same page.
C.
To be fair, the article does spend a lot of time talking about the problems of MFA when it really means a combination of certain implementations and social engineering. Uber, not known for any kind of best practices, is also not necessarily a good example.
Tar pits, where delays between attempts grow, are a good way of dealing with any kind of bombing and are standard on many systems.
I helped my wife teach all the users at her school not to open attachments - they had been told not to open all "safe" attachments but were ignoring the instructions so I gave her "Australia.exe" to send to everyone ... LOL, it just flipped the screen upside down so everyone was screaming!
But afterwards they understood what might happen.
"Educate your employees all you like but in an organisation of thousands or even tens of thousands of people people there's always going to be someone who fucks up."
Indeed. From my experience in a kinder, gentler, time there is a significant population of intelligent, capable people who simply can't be educated about some aspects of security. It's not part of their world view. They simply don't understand what you are talking about. The only way to discourage them from doing things they shouldn't would appear to be amputation of their mouse hand -- which is kind of drastic and probably illegal in many jurisdictions.
Don't think these users are the only ones who fall for phishing attacks. I'm well-educated about these and generally careful and able to detect them, but I've fell twice this year to company phishing tests, because I was distracted at the time I received them and the message made sense to me so I let my guard down and clicked on the wrong links. In the end, these campaigns are a helpful reminder that no one is infallible, that all it takes is 1 in a million to breach the defences, and that technology alone can't protect you.
>capable people who simply can't be educated about some aspects of security. It's not part of their world view.
That's why we need to up our security.
Send a MFA popup to their phone everytime they want to open/save a document, everytime their screen locks, everytime they want to read an email. For extra security we should also make each application use a separate authenticator.
Then they will be really careful about what pop-up requests they approve.
Yes. Don't think you can change your people to suit your computers. That has failed over and over.
Possession of a yubikey (or similar) beats possession of a phone for the second factor, not least because the phone number isn't terribly difficult to steal either.
As for locking out after N failures, I prefer rapidly increasing delays to successive attempts. It encourages the attacker to move on with less inconvenience to the user.
Smartphones are also fragile and common targets of theft. They're often difficult or unworkable for users with accessibility issues. Not everyone can afford one, and not everyone wants one.
As authentication devices they're an abysmal choice.
Meanwhile, Apple and Microsoft, among others, are back on the biometrics bandwagon, despite that being an obvious disaster.
Unfortunately many IT security experts are in such despair over the utter failure of password authentication that they'll grasp at any straw. You can see this in the editor comments in most issues of SANS NewsBites, for example. We're playing whack-a-mole, switching from one lousy, broken authentication pattern (passwords) to another (smartphone-based 2FA).
+1 for YubiKey and other dedicated physical authentication devices. Even dedicated TOTP gadgets like the RSA ones that used to be popular, or smartcards like the US DoD CAC, would be an improvement. Yes, they have their weaknesses too, but smartphones are just fucking awful as authenticators.
Seems like the YubiKey (or other separate and dedicated hardware token MFA device) is a win for defeating MFA flood/fatigue attacks.
Sure, a separate gadget may not be as convenient as an auth app on your phone, but security and convenience is usually the trade-off, eh?
I'm grey enough to remember carrying a 3des card around (about the size of the old flat digital calculators) and more recently whatever little gadget Microsoft required for MFA at $JOB. In the latter case Corporate IT complained about the gadget ("the cost money! Can't you just put the MS app on your phone?") but eventually relented when enough people resisted corporate software on their personal property.
I'm no security guru, but speaking of phone authenticator apps, is it somewhat contrary to BCP to have the MFA response provider app and the user password response in the same device, possibly the same device (phone, laptop) where you read email and other company activities?
E.g. one user described how their phone saved company passwords, auto-filled any challenge-response popups automatically, and supposedly the MS authenticator app for MFA did much the same thing. In the same phone. They were quite pleased with how easy it was, and required no additional steps. I figured I (or they) must have misunderstood something, because it seemed to me that such a pre- and auto-authenticated setup together on the same phone where you read your company confidential email etc. wasn't the desired behavior.
Two important points you just covered:
1) If the company wants you to use a phone app, they should provide the phone. Not just for your own privacy and ability to switch it off over weekend, etc, but also so said phone can have corporate requirements like up to date OS and remote find/wipe under IT direction.
2) It never ceases to amaze me that folks use the same device for primary and secondary authentication! Given how many relay on their phone for moving web access, having a MFA token that is physically independent avoids the sweet attack of getting the phone compromised (OK usually not as easy as Windows) and so gaining control over all aspects of MFA.
It doesn't take a lot of understanding ( and the crooks seem to have it) to realise that if you make accepting rather than denying the easiest option there will be some, perhaps many, who'll eventually just accept so that they can just get on uninterrupted. The marketing departments that stick cookies and stuff on our PCs know this.
Samsung's Smart TV people know this, blocking data slurping is a nightmare- or indeed impossible- because they've made it so time consuming and tedious, if you can even find it. Re-enabling everything you've painfully rejected takes just a moment of inattention. (Bastards)
The version of Android that came with Samsung's Note 3 had a similar bug (not saying it's a Samsung problem, it is an Android problem).
When an app wants your location, you're asked something along the lines of:
Allow "dodgy app" to access your location?
You are given a choice of Yes / No, and separately "Remember my choice". If you select No then "Remember my choice" is disabled.
Instead of putting up with that nonsense I installed lineageos on all 3 of my Note 3s. I bought a bunch of them second-hand because they were one of the last Samsung models that had a removeable battery, I would have gone for Note 4s but there were stories about the emmc dying.
Yup, and is part of why I'm now sporting a different phone. The wife abd I used to have Samsung phones but keeping Bixby turned off was a fucking nightmare. When you get it all turned off, and find all the "wait an hour and turn it back on again" crap found, they push an update that turns it all right back on. So, Samsung lost themselves a couple of customers over it. The only Samsung device I have left is an older TV, and when it comes time to replace that you can bet it won't be replaced by them. My other set is an LG, and it works pretty well.
This post has been deleted by its author
At the very least though, the MFA prompt can alert the user to the discrepancy, even after they click accept (e.g. hey we notice you're holding your phone in Australia but we have a login request from Russia - are you absolutely sure that's you?). And it can also be based on learning usage patterns - once the user has confirmed that they are indeed logging in from Russia enough times over a few days, the system comes to accept it. Multiple levels of imperfection, hoping to reduce the risk
The article appears to not mention the most sensible solution - using a 3rd party MFA app and prompting the user to type in the 6-digit code, rather than using any kind of SMS or notification. SMS should be a fallback only for users who insist they can't run an app and notifications should just not be a thing.
You can't bombard a user with notifications when there aren't any. This whole thing is bizarre - once again, our industry sucks - it never learns anything from past mistakes while simultaneously inventing new ways to fail. This is why I had to stop reading "comp.risks" in the end; the repetition was too depressing.
This. I never get bombarded with notifications for 2FA I have set up with Authy (about 40 different ones), because the model doesn't support or require it.
Of course I know why they do the 'buzz your phone app' thing, because they want to make it more conveeeeenient, but that always leads to giant holes. The 'IS THIS YOU?!?' design is just a complete misfeature, so easy to hit the wrong thing for instance. Steam uses an interesting way around this - you use your Steam app on your phone (which you're logged into) to scan the QR code they put up, so it's 'pull', not 'push'.
And of course SMS verification is just a complete abomination, so easily bypassed by people with the right criminal resources - which also happen to be the real bad guys.
yep just setup MFA to require a TOTP rather than a notification one. We have a mixture of both on various systems where I work. Lots of stuff these days use Azure AD for MFA and you can change your security MFA response to either be text a notification or a authenticator code but I have a feeling the default might be a notification
"..showing users what application they're signing into and the location of the device, based on its IP address, that is being used for signing in"
I think this can be counter productive. I'm often asked to verify that I'm logging in from Australia (a big place so not that helpful), or from Melbourne or Sydney (300km, 800km away respectively), Location by IP address is very hit or miss in Australia.
I understand this and can ignore the silly messages. I only verify when I'm sitting next to the computer and am causing the alert process.
Most computer users are at least a little less IT literate than me. Telling them they are being attacked by somebody 800km away will often not end well. In the end-user mind, telling somebody to ignore some details in a message is the same as telling them to just confirm every message. The topic of this article.
A further problem occurs when some installed software connects to the mothership at system start up, causing verification messages when the user isn't expecting them.
I like the idea of entering a code from the SMS message to complete the loop properly, even if I sometimes have to ring the guy who was previously in my job to get the verification code. His yacht is normally in range so this isn't much of a problem.
I don't think good reliable authentication is anywhere near a solved problem yet.
It's a blessing and a curse: I'm in a 'bad signal' area and regularly miss phone calls to the mobile, but as I do have Wi-Fi, I can get messages.
Why no Wi-Fi calling? Well... I can, if I ever bother turning it on. I'm at work: I don't need, nor want, personal calls: They can text or SMS and I'll call them back if I want to. (Me: Anti-social? Yup!)
There's quite a few things that could improve MFA:
1) Timer to limit the frequency of push requests (say, 5 mins apart)
2) Lock the account after X attempts (would suggest 3)
3) More info on the request...
4) OR: Have the request up on screen and display a number: The MFA Push includes that number so you can see and verify it's the request you're waiting for...
5) If a push MFA is rejected or there's no response, the next request pushes an SMS message with a code instead...
6) ... and then you could have a fall back on an authenticator generated code to enter to unlock the account to try the push notification again...
I've seen some of these in play: Normally it's when setting up an account but the ability to introduce things like an ID number would make it easier to know when it's a duff request, the ability to immediately lock MFA requests (a 'Hell no!' option) bypassing the 'reject x times', the option for an alternative code to unlock the primary MFA to avoid having to call anyone... a PITA to an extent but surely it'd be more user friendly and less bothersome that having MFA ping you every 10 seconds thanks to some scam artist trying to hack your account...
If you have an internal resource valuable enough to warrant MFA then allow access to it only via the company's VPN in the first place.
Your employees need access to work, right? So connect to the VPN first. There will be no MFA bombing then unless the criminal is inside the VPN already, in which case you'd have a bigger problem.
We do it both ways. MFN plus password to get on the VPN, MFN plus password to access any and all apps to include timesheets, don't use something for more than 10 minutes and you get auto booted requiring yet another round of MFNs and passwords. A full 25 percent of my work time is spent logging into stuff with MFNs and passwords.
I'm certainly glad I told The Boss that I have a flip phone, because I was able to get the MFN stuff on my laptop. My phone is blissfully free of any and all work apps, and will remain that way until work provides me with a phone.
Like that should work. You're part of my IT ? Then you don't need my access codes.
It's like the time, way back when, when I got a call from "my bank". After a minute of droning on about a security check, the guy asks me for my credit card number.
I said : "What ? Why are you asking me for my credit card number ? You are working in my bank, so you don't need me to tell you."
Then I hung up.
Not a long ago I received a mail from IT telling me to send them my logon password, so they could install my new PC. At first I though it was a phishing email or at a least a test. It turned out it was real.
When I stormed them and told them it was a very DANGEROUS procedure, making users used to send their password to whoever asks them - and that IT should NEVER impersonate me logging to anything with my own credentials, their piqued manager tried to assert I was attempting a storm in a cup... that was made just to make things "simpler"
IT hosts lazy people like every other department - when they are not stopped with a Cat-'o-five before making real damages, but instead promoted to management, the worst happens...
TBF - At more than one place we set up & configured devices prior to despatch or during a refresh.
I always CC'd in their manager, quoting the ticket number for their replacement device (Old one was usually been driven over by a combine harvester) & advised them the password would be reset at 5pm if they did not comply.
The default behaviour of phones' 2FA alerts also lends itself to theft. In London there's a thief (thieves?) who steal women's phones and credit cards and then rack up a huge number of purchases.
MFA usually falls down in making a mobile phone a "keys to the kingdom" item.
Given mobiles are easy to steal (depends on the phone and what authentication methods the phone owner uses how easy it is to get into the phone *)
I try & do as little as possible on my phone (no bank / payment apps etc installed- bar a few games that use a bit of internet access its essentially acting like a dumb phone)
* .. and that's ignoring the whole aspect of the non subtle approach of not surreptitiously stealing the phone but using a bit of street crime tactcs and using physical threats to get the phone owner to unlock etc.
Is it just notifications fatigue or really MFA fatigue ?
When I have an MFA notification, I'm expecting it, and take a careful look at it (ain't no SMS, but dedicated app) and I also check the notif code if any.
No risk to accept if not expected !
If, at contrary, your phone is buzzing every second, like some colleagues, then, yes, I understand you could accidentally accept when you were just spamming accept on dozens of notifications.
We allow MFA to be set up on a phone only when using the corporate wireless.
After that we block any attempts from outside the UK. If "Bob" really needs to log in while on holiday in Japan then he can request to be added to an exclusion group for the duration of his holiday.
3rd parties are added to a set up exclusion for no more than an hour and told they have 1 hour to set it up, after that they are then added to the UK only group.
We do have a couple of suppliers that are outside the UK but their accounts are disabled and they have to request access.
Let me get this straight.
You try to log on using system A, and device B pops up a message "Allow log in, yes/no"?
That's not multifactor.
Multifactor means Device B pops up a code for you to manually enter into A, thus proving that both are being used by the same individual.
Otherwise, HTF can the back end possibly even vaguely infer that both system A and device B are being used by the same individual?
Even if the user is perfectly diligent, spamming would mean they will eventually authorise a miscreant because the legitimate user was trying to log in at the same time.
Just because it's stupid doesn't mean they don't set it up that way. The stupidest one I get is from my phone provider. I log on using a browser, being very careful not to check the "trust this device" box. I enter my password and get a message, please enter the code from your phone, with a nice little box waiting for the code. Do I get a code on my phone? F no! I get a _link_ on my phone, click on the link opens a mobile page, allow access Yes/No. Which, as you point out, means I don't 100% know if I'm allowing access for myself or for someone else. It's _probably_ my own login. Anyway I choose Yes and I'm in. But given the phone provider doesn't even know their own authentication process (by the way they change it all the time), one day it might not be my own login I'm allowing.
I used to think that was weird.
Then we bought a fridge which happened to have a 'Sabbath mode' which we found out was so that ultra religious people could have a peaceful holy day (see: https://www.hunker.com/13409700/what-is-sabbath-mode-for-refrigerators).
After that I thought it was weirder.
This post has been deleted by its author
At my last employer, I got an email from Amazon saying someone had tried to access the company account from a new machine. I responded with the "this wasn't us" button push.
However for reasons never disclosed* Amazon ignored that and the account was used for £20,000 of fraud before being locked.
To add insult to injury once the perp had access they removed our company login and changed the email address. Meaning Amazon wouldn't talk to us, since we didn't know the email address.
after 10 hours (I know, I recorded the calls) of dealing with their "customer service" the lawyers got involved.
*You can't get to speak to Amazons fraud team directly.
I have the call recordings, escalated to the US. I know WTF I am talking about.
Incidentally, all the fraud was unwound, and Amazon suddenly lost interest. Which was a PITA as the fraudster (turned out it was an ex employee) also managed to get some loans using the company accounts. Testimony from Amazon around the timing would have helped an awful lot. But it seems like Rolls Royce breakdowns. Amazon fraud is a myth.
This kind of waning overload fatigue has long been known in the aviation industry. Around 40 years ago commercial pilots became so overwhelmed by the ever-increasing array of sirens, klaxons, buzzers, bells, beeps, lights flashing and steady, that they took to switching much of it off. More and more accidents started to happen because the pilot either didn't notice, or had switched off, the one warning that did matter.
The solution was to embrace warning management as an ergonomic aspect of soft system design in its own right, and to apply it from the ground up in designing the cockpit environment. Often that simply meant recognising the seriousness of a given potential overload threat and raising its engineering priority from maybe-later to oh-shit-right!
We scrotty little IT newcomers have a lot to learn, not least that "hard" systems engineering, even with a dash of UX fairy dust, is hopelessly unequipped to deal with these issues. Nor do the employers of IT developers care to pay for such soft-engineering approaches to their products. Expect a long, hard winter of cyberfatigue before AIs get good enough to do a decent job for the average Jo.
Funny, we watched an episode of Mayday (Air Crash Investigation) last night where precisely such a thing happened, at the CORPORATE level. A French carrier wanted their pilots to fly as fast as possible; IIRC they had a standard of 350 KM/H when below 5000 feet, as opposed to 250 KM/H for standard flights (something like that anyway). They found that the terrain warning alarms went off too often in this configuration, so they began ordering aircraft without terrain warning systems.
Surprise, they had a plane crash into a mountain.
This was some of the feedback the Qantas pilots gave Airbus after the A380-grenading-an-engine-in-Singapore case... They said that way too many messages were being displayed by the FMC and most messages being less than applicable to the actual situation at hand.
Airbus took that seriously and has apparently done something about it. But since I'm not a pilot, and there hasn't been a repeat of the incident since, I have no idea whether things have improved. But at least the scenario did make it into the flight sims too.
Whatever happened to single-sign-on? Since the advent of the everything-online-cloud-obsession I now have to login to 5-10 different systems every single day, and that is before I even start to remote access the customer systems I support. I am not even remotely surprised that people are MFA weary, and login weary. I long for retirement so I will no longer have to consult my Password Manager 30+ times per day. I am all for securing systems, but when the system is so secure that it is preventing legitimate use or considerably slowing down access for legitimate users, then there has to be a point when someone says ENOUGH ALREADY! Otherwise we will all end up on standalone systems with no wired/wireless networking and powerline filters in an underground nuke proof concrete bunker.
Problem with SSO is that some SSO systems are so badly implemented... There's a plethora of protocols that offer SSO (SAML, OpenID Connect, etc), and when 'new' protocols are invented they all turn out to be just as crap just with a pretty little interface that's slightly different to the others.
Also, given things like 'Sign in with <vendor X>' are proliferating (particularly on social media), and those accounts end up being compromised, SSO is not the panacea that everyone thinks it is.
I have worked in the SSO space for 9 years, and quite frankly, while it makes things easier in the sense that you can easily log into the appropriate 'thing', I'll stick to my password vault because *that one* *I* control... no-one else. Should I choose to leave any of the social networks (or move my mail somewhere else, or... or... or...), I don't have to re-jigger everything not to use those accounts anymore.
Case in point is the current Muskapocalypse where thousands of Twitter staff suddenly find that their Google mail (where Twitter hosts mail) is locked out, and everything else they use too. While the warning not to use company accounts for stuff should be a standard one, it's come too late for some of these...
> We scrotty little IT newcomers have a lot to learn
Yes, every decade I see the same human-level mistakes made all over again. Because corporates assign the designs to wet-behind-the-ears newbies, who don't know the field and have not seen those same mistakes made over and over.
> HTF can the back end possibly even vaguely infer that both system A and device B are being used by the same individual?
Presumably the individual designated phone 123-1425 as device B for system A.
> A clock on a fridge?!
Yes, that bothered me deeply. I already have too many clocks.
> "It's an attack method which preys on the employee to be a human," John Spiegel,..told The Register.
Well. The answer is clear. Don't employ humans. Hi, robot overlords! And they don't need clocks or refrigerators.
Presumably the individual designated phone 123-1425 as device B for system A.
*sigh* You might want to think about this for half a second.
Miscreant attempts to log into system A at roughly the same time as you also attempt to log in.
You get a notification. Do you say yes, or do you say no?
Let the right one in...
(And remember, users don't read anything unless forced.)
Push and Frictionless are incongruent and attack vectors have shifted from social to psychological and biological (muscle.memory). 1click auth is fundamentally flawed since that is now all it takes to indavertantly approve and login a threat actor.
Starlogik has created the only Mobile Orignated above Internet band Identity Access Management (IAM) protocol that delivers millisec signaled frictionless authoritative cellular network generated cryptographic keys for passwordless access and seamless irrevocable billing certificates for micropayments on any phone out the box.
The idea of putting this all on the user is moronic. Instead of a 3 second pop-up that blocks access to their device(possibly while they are trying to open a support ticket to report it!) where they are one click away from enabling a breech, the focus should be on cleaning up the usability and tackling more of this issue on the back end.
Unless this MFA flood is being generated from malware on the users device(You have bigger problems) the user needs to be clearly shown where the connections are coming from, and given the option to block subsequent attempts. That last part may not be a one size fits all option. This is where the push notification may need to give the user an verification code to enter in on the devices they are using, or given a chance to (for example) kill all connections but the ones they are using and block new logins for other devices for the next x number of hours.
It, in a organization, should be flagging the even, the users response, and firing notifications to the IT staff. It should be logged to the SIEM, and in a better world, available to things like the IPS/Firewall to block the attackers access to the rest of the organizations resources without locking out the impacted user.
Right now many of these systems aren't even smart enough to keep the same attacker from logging in to other accounts from the same connection an end user just declined.
A truely evil one would let the IT staff redirect the attacker to a honey pot, and forward the results to the FBI. Congratulations, you just won a free felony conviction!
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
