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.
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"
This is false, GDPR is opt-in.
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?
Um ... huh? GDPR requires explicit consent.
Airtable did something similar recently with the grandfathered free accounts
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.
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.
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.
For a disgruntled employee (most employees), getting hacked is a win-win.
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?".
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.
(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).
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...
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 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.
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.
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.
Different strokes for different folks. I care to have folks be successful.
If this still doesn't work for them, perhaps a hardware token they can tap might be a better solution.
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.
If this still doesn't work for them, perhaps a hardware token they can tap might be a better solution.
If this still doesn't work for them, perhaps a hardware token they can tap might be a better solution.
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.
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.
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.
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).
What a shit show. It's a weird thought that people use this crap in allegedly secure environments.
This is their blog when they announced it: https://monzo.com/blog/2018/08/22/launching-3d-secure
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.
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.
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?