MFA via "Is that you trying to login?"

[britechguy]

So, I've been wading into the waters of 2FA using 2FAS (also Google Authenticator, but not right now), and it works well enough, but I find it a grand PITA to have to enter those 6 digit codes after also doing the classic loginID/password sequence. There are some services, Google being one of them, that will throw up a message (and not a text message) on the screen asking, "Is that really you?," to which you respond using a yes/no button.

If I'm going to attempt to get many of my clients to accept 2FA, the 6-digit code entry will be a no-go, but the, "Is it you?," method would easily fly. Is there a way to force that to occur via some Authenticator App setting I'm missing?

 

[thecomputerguy]

So, I've been wading into the waters of 2FA using 2FAS (also Google Authenticator, but not right now), and it works well enough, but I find it a grand PITA to have to enter those 6 digit codes after also doing the classic loginID/password sequence. There are some services, Google being one of them, that will throw up a message (and not a text message) on the screen asking, "Is that really you?," to which you respond using a yes/no button.

If I'm going to attempt to get many of my clients to accept 2FA, the 6-digit code entry will be a no-go, but the, "Is it you?," method would easily fly. Is there a way to force that to occur via some Authenticator App setting I'm missing?

I think only if the service office push as an authentication method which O365 does.

Or make your life easier and use a password manager that allows you to store 2FA codes with the login like 1Password.

Just make sure your password manager doesn't get compromised.

Using your password manager to store 2FA codes is pretty much like 1.5FA not really 2FA since your password manager holds the keys to the kingdom.

 

[YeOldeStonecat]

A few years ago as we started getting clients on with MFA.....I had found that the simple "Approve/Deny" approach that Microsofts authenticator defaulted to....was really nice and easy for clients. Esp when doing the dance of the stack of cards on smart phones....when configuring email clients.

However, this thing called "MFA Fatigue" became a thing. We found that...clients got in the habit of rushing to "shut that phone up" throughout the day by just hitting "Approve"...without stopping to think about it. Despite my speeches to them...."Now, you should only expect to see that when you're signing into a service that requires it....so, pay attention and think. If you're sitting on the couch at home, after dinner..and your phone goes "ding"...and you see the "approve/deny" prompt there...STOP AND THINK...am I signing into something? Nope...wait..oh...no..that's not me....I'll hit "Deny". Heh..well, yeah, they still just hit "approve"..and let the bad guy in the back door!

Microsoft realized this was a bad idea, so they came up with a more advanced approach that is still easy...but...really had to get "tricked". It's called "numbers matching". When you configure something with your 365 account...with and you set up the Microsoft Authenticator on your phone, if/when you sign into a 365 service, what the numbers matching does is...on the computer with the browser or app signing in..a windows appears with a 2x digit number.

..and then..in the Authenticator app on your phone, a window comes up with a blank field awaiting you to type in those 2 numbers. And also a map shows up above it..with the geo location of the sign in attempt. As well as...a name of what the app is trying to sign in.

...so...it's as close to darned impossible for an end user to "let the bad person in"..with this approach. If they're on the couch watching TV and this prompt comes up on their phone, they would not know what number to type in it....!

 

[britechguy]

@YeOldeStonecat

I have no problem with the "Enter the 2 digits" methods, either. I like them for the same reasons you do.

What I know will end up not flying is the need to enter a 6 digit code that the end user must look up in the authenticator app.

Essentially, this comes down to something you've dubbed MFA Fatigue and actual MFA resistance because it's too darned inconvenient. I've been in this game since the mid-1980s and every "genius inspired security protocol" has eventually fizzled because end users find them onerous.

 

[YeOldeStonecat]

I wish I coined that phrase, but it's a few years old already across the industry....

Here's a link to Microsofts article where they implemented this "much safer MFA approach".

Defend your users from MFA fatigue attacks

Recommendations you can take to keep users safe

techcommunity.microsoft.com

And a picture showing the "numbers matching" method...

 

[britechguy]

Am I safe in presuming the numbers matching method only applies to:
1. Microsoft Authenticator
2. When being used with Microsoft-owned sites?

 

[HCHTech]

Just make sure your password manager doesn't get compromised.

Right. I'll get right on that - haha. I WISH we had some control over those things. If you use a self-hosted solution you are more in charge, but I've never even looked into that. We use Bitwarden, but in the end we're just hoping they don't do something stupid!

 

[YeOldeStonecat]

Am I safe in presuming the numbers matching method only applies to:
1. Microsoft Authenticator
2. When being used with Microsoft-owned sites?

I've not seen "numbers matching" elsewhere....although, the technique may be used by others soon/down the road, if not already.

Also, Microsofts Authenticator is quite compatible with TOTP of other brands....I use it for my Google account, Facebook, LinkedIn, and over 20x other services.

 

[Sky-Knight]

Right. I'll get right on that - haha. I WISH we had some control over those things. If you use a self-hosted solution you are more in charge, but I've never even looked into that. We use Bitwarden, but in the end we're just hoping they don't do something stupid!

They have the same internal problems as Lastpass... they aren't managing your KDF iteration count, and they will not enforce stronger master passwords over time as the master password.

The only difference between them and Lastpass is they have internal audits and external ones that iterate and shine a light on these things in advance. But they would have fallen just like Lastpass did, and they announced this themselves I think March or so?

 

[britechguy]

But they would have fallen just like Lastpass did

You can speak directly to this, but if "would have" is no longer "would" then lesson learned. If they've taken steps since to address the weaknesses, there's not much more you can ask.

 

[Sky-Knight]

You can speak directly to this, but if "would have" is no longer "would" then lesson learned. If they've taken steps since to address the weaknesses, there's not much more you can ask.

Correct, which is the primary difference between Bitwarden and Lastpass as companies. The former noted the issues impacting the latter, started an internal review... did the OH CRAP thing, then changed course. They didn't wait for a breach, they changed operationally to address the problem.

They remain impacted by the lack of automatic increases of KDF iteration counts, they also remain impacted by the lack of enforcement of proper master password strength. They did however mitigate this with a huge education campaign, for those that were so interested so that customers could mitigate these things on their own.

I'm by far not a cryptography expert, but the documentation provided by Bitwarden over the years is one of the primary sources I've used to defray my own ignorance. They were also among the first in the password managers to officially support Argon2, which is supposed to be better than PBKDF2 at resisting decryption attempts. Again I'm no master in this space, but what I do know is the former has far more study than the latter, so I'm still using PBKDF2, with a 600000 iteration count. I might be safer on the younger method, but no one can really say that for certain yet.

Again, Bitwarden taught me much of this, at least it was enough to let me to further research to get supporting sources elsewhere. Lastpass did none of this... Which is why I use the former. I cannot really ask for more than what Bitwarden has done.

 

[britechguy]

They didn't wait for a breach, they changed operationally to address the problem.

Yes, but they could well have been the first breach, rather than LastPass.

I'm not saying that this is the case with LastPass, because I don't know, but there are many breaches that are not the result of lack of preparedness with what is known, but they occur because some malicious agent finds an attack surface that is (or was) an "unknown unknown" and promptly proceeds to exploit it. There is no way to prevent that, at least no reasonable way. Someone has to take a hit, first, before defenses can be designed.

By contrast, what happened to Rackspace, as but one example, was entirely within the realm of prediction, and it was inadequate preparedness for already known vulnerabilities that allowed it. [That might be true of LastPass, too, but *I* don't know that. Others might.]

And I'll say it again: By definition you cannot defend against unknown unknowns. That's the definition of an unknown unknown - you know absolutely nothing about it or its potential existence.

 

[Sky-Knight]

@britechguy That's fair, and I also do not know how LastPass functioned internally leading up to the breach.

What I do know is they were not forthcoming or transparent at all about the breach itself until well after the holidays, and by then the weaker vaults were already open. That's the bit that made things unforgivable... breaches happen, and transparency is critical.