Microsoft's MFA is terrible. You install an app called Authenticator. Then when you login the Authenticator app gets a push notification, and the user has to say whether to allow the login or not. If you accidentally press Yes, the attacker gets in. And here's why this is a serious problem: When you use Remote Desktop to work, any time you have a network issue RDP automatically reconnects and you get an Authenticator notification. So during the work day you get frequent prompts that are automatically initiated by RDP reconnects. You get used to automatically saying Yes to the prompt. So when one of these prompts is initiated by an attacker's login there is no way to know, and you automatically answer Yes.
I'm always on the edge of my seat waiting to learn what mind-blowing technique the "band of elite hackers working for Russia’s Foreign Intelligence Service" came up with. And it's always something along the lines of "they kept sending emails until somebody clicked the link."
Crusty person with an opinion here.<p>Google wankers forcefully added "Google Prompts" as a 2FA method, without consent, and disabled removing it. Of course people are going to hit "authorize". Oh and if you remove the Google app, you can thankfully use the YouTube app (like that's a good idea). A _video streaming_ app now has the keys to the kingdom. Man I feel secure.<p>Just use hardware keys. It's not difficult. My 70 year parents use them. I explained "This is like your front door key, but for you account. It's safe to put this in whenever the computer prompts you for it."
I would expect that an engineer would recognize that (1) a massive volume of MFA notifications is extremely suspicious and should be reported immediately to security and (2) if they are trying to sleep they can just mute or turn off the phone. This was a major failure of training.<p>For a nontechnical employee I could get how they could not recognize this as an attack. But if you are getting annoying calls and don't know why, why not just unplug/turn off the phone?<p>On the other hand, slipping a single MFA notification in during the normal workday seems like a much better approach. Even if the employee doesn't accept the notification, they'd likely assume that it was a tab they opened earlier and closed before finishing the login, not something to report.
I've noticed that Google actually randomizes the position of the Accept and Deny buttons on their 2FA popups. I guess this is to force you to read the entire text, but I have on more than one occasion Deny'ed my own request because of this. I think someone would have to hit me with about 4 2FA requests before I ham fisted the wrong button.
> <i>no limit is placed on the amount of [2FA phone] calls that can be made</i><p>I thought this was going to be a story about one-time password interception [1]. Instead, it's something much, much dumber.<p>[1] <a href="https://krebsonsecurity.com/2021/09/the-rise-of-one-time-password-interception-bots/" rel="nofollow">https://krebsonsecurity.com/2021/09/the-rise-of-one-time-pas...</a>
> That’s where older, weaker forms of MFA come in. They include one-time passwords sent through SMS or generated by mobile apps like Google Authenticator<p>That reference to Google Authenticator being weaker is not consistent with the rest of the article.
Isn't manual TOTP MFA (using codes generated by Google Authenticator or similar) significantly more secure than those MFA prompts? I don't understand the push for MFA prompts when the previous technology worked just fine and was probably more secure. What's the benefit to MFA prompts other than slightly better UX?
Currently I only trust these 3 factors of authentication used in combination correctly:<p>1. Memory (enter the site-specific password via the password manager which is unlocked by a password is from your memory).<p>2. Device (device-internal-hardware backed certificate bound to this device).<p>3. Physical Presence (FIDO2 Key touch)<p>Most importantly, it is extremely important how secure the reset auth flows is.
And if any <i>one</i> of the three factors need to be reset, then the system should require the other two to be valid, plus it should require an in-person identity verification (if implemented correctly, video KYC should be acceptable). Plus there should be a reset-buddy designated by the user who should second/vouch the user's initiation of reset.<p>Without all of these (2 factors of auth from the user plus system automated video kyc + reset-buddy vouching), even the admin shouldn't be able reset auth of any accounts. This is crucial.<p>Plus there should be a pre-cooloff period after reset request is raised but before it is actually processed, and a post-cooloff periods for any additional factor reseting, and regaining full privileges.<p>Independently, there should be fraud/risk systems for safeguarding any sensitive operations (like creating additional users, exfiltration of data etc).
I gave a talk on that almost 20 years ago...<p>Basically you have (1) something you know (like a password), (2) something you have (like some device or key), and (3) something you are (like a fingerprint and iris scan).<p>Back then the accepted trade-off was that have any two of these three is good enough for most case, and for really critical stuff you need all three.<p>The MFAs in question here attempt (1) and (2), but do a bad job on (2).
If they could login without knowing the password when MFA is enabled, then 2FA/MFA is making it less secure than simply having a strong password and nothing else.
Some of this is expectations and how you train your users I think.<p>I know at least in my experience, running a Windows machine I can get random prompts to sign-in at random times from Outlook, Team, Visual Studio for Azure resources, from powershell scripts with zero context as to what they are for.<p>Some of them will prompt for login, as I have multiple AAD account, others will just pick one AAD account and skip the password as things are cached.<p>I'm then getting seemingly phantom login prompts and phantom authenticator requests by design. I'm denying them when I'm not certain what they are, and for secure environments I'm using a yubikey - but that's not what I expect most people to do faced with this.
Can't wait until companies expand their fake-phishing email programs to include this. Randomly like once a month your phone will get spammed at 1am and if you allow the request, then you have to attend a phishing training session.
this reminds me of Interactive Broker's iOS MFA.<p>if someone tries to login and you happen to be using their app, the face ID triggers automatically without prompting you to accept.<p>you would have to be very fast to point the phone away from your face to avoid it.
One job I worked on involved updating my employer's authentication and bringing in MFA and other modern authentication techniques. We initially enabled just the MFA that required the use to have an authenticator app and enter the code into the site along with their password. Guess what? That didn't satisfy the product owner or marketing, so we were required to enable the other form of MFA, which sends a message to the user's device and requires them to just press the OK on the app and allow it.<p>But at least we were able to hold the line on sending one-time codes via SMS.
No one external should be able to trigger this, it should only be the owner that takes action of, e.g., opening a code generator or requesting an SMS/phone call through dialing from the right number.
The article seems to lump Google Authenticator and push style authentication prompts together (as old broken MFA), but I'm unsure how you spam someone with requests for the former?