Hacker News Reader

Comment by petilon | Hacker News Reader

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.

View on HN

Also for other similar MFAs, if there is no rate limiting and the attacker spams the user, the user gets an unwanted notification and says no. The immediately gets the next unwanted notification and says no. The user doesn't want to deal with MFA, they want to use their phone, and the notifications are in the way. The user's primary goal is to make that stop. The logical thing to do is clicking "no", so the user does that.

But that isn't working. Every time the user clicks no, a new notification pops up. Eventually the user learns: Clicking "no" does not work, it does not achieve his goal. If it hasn't worked 5 times, it probably won't work the next 100 times. So, the user tries something different.

(And the best part it: It works!)

The solution for this is obviously to provide a "no, and block requests until I open the app" button.

This is also why basically all GDPR consent trackers are "accidentally" so forgetful about your choice not to consent. You need to say no every single time (with potentially shifting interfaces). Similarly if I remember correctly WhatsApp would repeatedly ask you to accept the new terms of service with pop-ups until you one day accidentally mis-click on the consent button. I honestly don't understand how that would count for anything, legally speaking. But don't expect much help from the legal system here - think of how often we have said no to EARN IT, yet it keeps coming back. One slip though and you're stuck with it.

Yeah I also accident accepted the WhatsApp terms after months of periodically denying, and I feel raped.

Airtable did something similar recently with the grandfathered free accounts

Thank you for downvoting me, airtable marketing crew lol

Just like the IRA said to Thatcher: "Today we were unlucky, but remember we only have to be lucky once. You will have to be lucky always."

>This is also why basically all GDPR consent trackers are "accidentally" so forgetful about your choice not to consent

They're perfectly entitled to track you as long as you don't opt out.

And when you opt out, they can't be held responsible for remembering it for even an instant, because they can't identify you.

"That's some catch, that Catch-22"

Yeah, one website I visited recently helpfully showed me the cookies that it would save if I accepted their cookie agreement. The first one on the list was the cookie to remember my response to their cookie agreement.

This also makes the cookie prompts a pain for users who don't use cookies. My browser rejects all cookies by default, so I end up creating uBlock filter rules for the prompts on sites I frequently visit.

> They're perfectly entitled to track you as long as you don't opt out.

This is false, GDPR is opt-in.

Irrelephant.

Since you didn't opt in, you haven't allowed them to track you, and they can't remember that you didn't opt in without tracking you.

See?

> They're perfectly entitled to track you as long as you don't opt out.

Um ... huh? GDPR requires explicit consent.

Whatsapp also helpfully nags you constantly to enable notifications if they’re disabled and to enable (unencrypted) backups to the cloud.

This is illegal under GDPR, but enforcement is currently overwhelmed with violators.

The solution is obviously to not show a notification at all, ever.

If I'm trying to log in, I know that I have to go into Authenticator and approve, so just check if there are outstanding requests (e.g. with a 2 minute timeout) when I open the app.

Except that's still a failure: the attack can script that to ensure there's always a notification. Doesn't have to get it right then and there either - they have infinite time. Might be this month, might be next month.

The user interaction of classic TOTP forms an important grounding function: it forces (in most cases) spatial locality of the user and the device being interacted with.

Some providers also give a unique identifier to each request. I always check them if it's present. Also, having multiple selections (numbers) also prevents this attack somehow. Your prompt says 7/56/9, but neither is there. So what? Or, you have the number in your prompt by chance, and it's not the right choice for that prompt.

Nevertheless, at the end of the day the buck always stops at the user. User have to be diligent and shall have no blind trust on anyone/anything.

If a hacker uses my account to hack my employer via Microsoft's terrible MFA, it's not my problem. The buck stops, as always, with the person who cares about the resource being accessed, or who is made to care by being legally liable.

For a disgruntled employee (most employees), getting hacked is a win-win.

That's an interesting take.

Let's change names.

What if it's Google, Blizzard / Epic (Battle.net), and something personal? These services use the same flows.

Or worse, what if it's your e-Government app, and you lose all your identifying information and somebody can become "you" with all the information they got?

Will you say "Meh, it's a personal account, and I gave access via MFA, but who cares, it's not my problem?".

Google did something even worse with old Google Drive links.

I published a link to some documentation back in 2017, and set the permissions of the link to "view".

Google, in their infinite wisdom, decided that somehow this link wasn't secure enough and now send notifications to my tablet every time someone clicks to manually authorise access.

This would be a pain in the arse at best, but they've somehow managed to fuck things up even more. By default, the permissions I'm granting to the user through these notifications is set to "edit".

Just to reiterate, they've "improved security" by spamming me with notifications to grant random members of the public full edit permissions on document that was intended from day one to be publicly accessible.

I just weep sometimes.

This might be the individuals clicking to request edit access on the Doc: https://support.google.com/docs/answer/6239515?hl=en&co=GENI...

It wasn't that. They sent me an email to tell me that I needed to regenerate the link for security purposes and after date x it would no longer function as normal.

That might be a "we need to change how we're generating URLs because we want to refactor stuff / not support the old format because it was too guessable or something" thing.

I think that was for a simpler problem, that shared urls were not unique enough, and could be guessed or brute forced to get random peoples shared items. The articles published by google seemed to warn that there was an expectation gap on the amount of privacy people should have expected to have on them.

For context on what's happening here: https://support.google.com/a/answer/10685032

(Disclosure: I work at Google. I used to work on Docs & Drive, but don't anymore and don't have any special knowledge about this).

That's people requesting Edit permissions.

You can disable Edit requests (and avoid "link" sharing) by Publishing the file, which is different from sharing a /view link.

https://support.google.com/docs/thread/28614984/remove-reque...

Your dislike is probably more due to the configuration setup in your instance.

As others pointed out, you can require matching a pin in the app with the one on the screen.

With many of the MFA apps I have tied to Microsoft products, they typically store a session expiration where they don't have me re-authenticate with MFA until the next day.

I've worked with many enterprises where the security group implements awful policies in an attempt to lock things down but instead create more risk by creating to much burden on employees which results in them finding clever hacks around the security.

Just guessing, but probably not the tool here. Though they maybe could improve their defaults, docs or UI/UX.

The problem with giving options regarding security is that sometimes the people who are responsible for setting up those, forget about "convenience versus security", or they get pressured by other groups to "forget" about that balance, and makes a lapse of judgement.

We could, by laws and software, enforce a certain standard of security for organizations. The question is how liable you should be for that. Would have to consider many variables like size of company, importance of information and such.

> more due to the configuration setup in your instance

The obvious question here is, why does it have a configuration that allows an accidental or absent-minded employee to let in a hacker? Other authentication apps such as Symantec VIP does not use notifications, so the employee does not respond to a notification, instead he proactively starts the app to get a numeric code. Less convenient than saying Yes to a notification, but more secure.

I work with a few older employees. Its takes them longer to focus on the words on the screen and to read them (presbyopia happens). It takes longer to get into an app and read a code out. By the time they are ready the code is already changing in the app. It is much easier for them to touch an acknowledgement. We want security but we do not want to make security an impossible barrier for folks that need a little extra time (for whatever reason).

The code is valid for another full minute, typically, after it's rotated for a new one. This isn't much of a valid reason to prefer notification-based 2FA.

It is not obvious to everyone that a code may still be valid after its gone from your screen. You cannot use the first 3 digits from one code and the last 3 from another, so you start over when you don't have all 6 digits before the code changes on you.

Different strokes for different folks. I care to have folks be successful.

This sounds like an education issue; if you were to say "wait until the code changes, then go for it", they have thirty seconds to read and type six digits.

If this still doesn't work for them, perhaps a hardware token they can tap might be a better solution.

TBF the code still being valid doesn’t help much if the user hasn’t memorized and/or finished typing it all.

Sitting next to some family members, they really can’t remember more than one or two letters at a time, and will peck and hunt each of it. Except if they were typing the last digit, the code disappearing from screen is basically the end of it for them.

In cases like these, I tell them "wait until the code changes, then go for it", so that they have thirty full seconds to read and type six digits.

If this still doesn't work for them, perhaps a hardware token they can tap might be a better solution.

There certainly are people for whom "a full minute" is not sufficient - accessibility is important.

If you were to tell them "wait until the code changes, then go for it", they would have thirty seconds to read and type six digits.

If this still doesn't work for them, perhaps a hardware token they can tap might be a better solution.

Semi related: apps which display TOTP tokens should start their timer when the user opens the app (so the code doesn't change 5s after opening the app). The server in the backend is checking the previous+next N tokens anyways since the server needs to account for clocks not being 100% synchronized.

Unless the authenticator app was already open, in which case skipping to the next token should be possible on demand.

Alternatively, we just found the semantic use case for the <marquee> tag: a properly calibrated scrolling ticker would give readers the clear option (regardless of initial phase) to start reading the newest token or continue reading an older one, as the ideal selection may evolve unexpectedly based on distractions.

The trade off here is that many non tech organisations make MFA at all a political difficulty. I've sat in on several meetings about how we can reduce the difficulty of using Microsoft MFA, with people talking about preinstalling it on people's phones and of course, "let's do away with MFA" comes up quite often.

Many of those orgs looked into RSA tokens in years gone by. The only reason that MS auth got through when those devices were summarily rejected from ever being used, was the convenience.

The security industry needs to be careful here. Too much "Microsoft MFA is bad" and I'm certain many companies will simply revert to password-only, in much the same experience we had with SMS based MFA being bad and as such, web apps going live that simply didn't support MFA.

Don't you have to provide some information as part of the confirmation? Whenever something requests MFA, it will show a two digit number, and in the Authenticator app, I will be presented with three numbers and can only confirm the prompt if I select the same number that was shown by the requestor. My work MSFT account is even more locked down and requires me to type in the number.

No, if you are on iPhone, Face Id authenticates, then you press a button to allow. That's it. There is no number to type anywhere.

Oof. I wonder if admins can disable push notifications and just fall back to TOTP instead? Though it does sound like that would not be convenient if you have to enter a TOTP every time an RDP connection get interrupted.

... you can still do the code based flow if you want...

I want to see what the execs use, not the code monkey "requirements"

For Office365 / AzureAD this is a configuration choice, admins can enable the numbers option which reduces the chances of accidental allows

Sorry but the parent poster is correct. For both my corp account as well as my personal Microsoft account , I’m prompted to enter the validation number after I’ve faceid’d. If this doesn’t happen when you are authenticated, then it’s a setting with the system you’re logging into.

Same here. We disabled the push notification for Corp, but my personal account requires me to select a matching value.

Administrators can enable it. If they have it set to 'Microsoft managed', number entry is enabled by default but not additional context. https://docs.microsoft.com/en-us/azure/active-directory/auth...

Depends on config. Bare minimum (mainstream?) is just a "blah blah service login" Accept|Deny.

If you are in and out administering things and accessing protected documentation I could see how the login-to-mfa-popup latency and difference in tenancy names could give a window for a misclick.

Duo also works this way

Luckily, MS also allows for FIDO2 and TOTP authenticators so you can make it a lot harder for criminals to get in. Especially with FIDO2 keys, you're pretty unlikely to get phished.

As sibling comments indicate, there is an option to make the request for MFA more secure by providing a number to match your request, but it's pretty dumb that this security feature is disabled by default.

> Luckily, MS also allows for FIDO2

This is not universal. It works on Windows with most browsers, but doesn't work on Firefox on Linux (works on Chrome on Linux) nor on Safari on Mac, nor Safari on iPhone, nor Teams on Linux (haven't tried Teams on Mac nor Windows).

The number match still only give you 4 options so 25% chance of entry on Mis click

When I had to use Windows for work (man, I'm glad I don't anymore) I used to get a ton of random password prompts (Sophos VPN, some Microsoft 365 or Windows accounts) with absolutely no way to tell whether they were legitimate or what triggered them.

What a shit show. It's a weird thought that people use this crap in allegedly secure environments.

I quite like Google's approach, where you don't get a notification and have to go into the app to get the pop up. My bank does the same thing, you have to go into the app without a notification, see the pending transaction in your list and then approve/reject it. Feels a lot safer than push notifications for sure.

Your bank lets you approve and reject individual transitions in real time or just ones that get flagged by them for fraud?

It’s their implementation of 3D Secure for online payments, which I think is based on a combination of heuristics and the merchant opting in/out. It’s a very good UX though, banks I’ve used in the past would ask you to enter some characters of your password on a weird looking 3D secure page.

This is their blog when they announced it: https://monzo.com/blog/2018/08/22/launching-3d-secure

Except the push notification still requires you to authenticate with a biometric before it’ll open the app and fill your TOTP, ask your for a number to enter in, or approve the login. It’s not like you just tap it and you’re fine. You have tap and then log a biometric or PIN.

You can turn the push notifications off or they are a concern, but I think it’s a bigger problem to allow stuff via biometric so passively.

Personally, I like not having to switch to a Home Screen to open an auth app to approve or copy a code. Having it pop up for me and take me to where I can get stuff to auto fill or approve/enter in numbers is a really nice feature.

It's not Microsot's MFA, others do this also. It's push notification authentication. Better than SMS in that sim swapping or ss7 type attacks won't work on it. They also support yubikey/fido, it's up to your AAD admin to allow any of those.

I haven't been able to understand what that lengthy article talks about, but with your short comment it is clear now. Why Authenticator needs push notifications, it's so stupid. I use Microsoft MFA with Authy without any problems and without any notifications.

This is not always the case for Microsoft Authenticator. When I get a prompt on my iPhone, yes I need to use faceid, but I also need to enter a random number to “prove” a human has indeed accepted the auth request.

For most users, they’ll only get a prompt when they login to a new device, so the risk of notification fatigue is lessened, so I think it’s OK on that front.

I agree however that admins are constantly bombarded with alerts and can suffer from vigilance fatigue. I think there is certainly a need for a different approach for more privileged users - it could be as simple as red banner, instead of the blue theme that is common across the MS, SalesForce and Okta MFA apps.

Any time I need to get into my work account, the MS Authenticator app on my phone demands that I give it my thumbprint or enter a PIN.

Also they want to lure you into using their own app by hiding the little link that allows you to get a normal OTP code.

That bugs me more than anything, I don't want another app! I have over 30 codes in my open source OTP app, how would that even look if everyone wanted me to use their app?

Not sure when you worked there, but I’ve seen that you have to enter a number that’s displayed on the device logging in, and the authenticator app shows the location of the device attempting to login as well.

Reply on news.ycombinator.com