[antithesis-nl]

Yeah, can confirm, there are a lot of targeted emails going out inviting people to dodgy auth flow endpoints.

Disabling device authentication (which is rarely needed anyway) and forcing Microsoft Authenticator (with the yes-this-is-really-me number entry thing) or something like a Yubikey should make your org like 99% less vulnerable. If you're not on a Microsoft-or-similar platform (good for you!), one word of advice: passkeys.

As for the inevitable "who would fall for this" question: prior to 2017, when Google instituted a strict 2FA policy, even members of their elite security team were successfully phished. After that, not so much: https://krebsonsecurity.com/2018/07/google-security-keys-neu...

[semi-extrinsic]

Honest question when it comes to 2FA like MS Authenticator: why don't they ask for the 2nd factor first, and password second? Sounds like it would make it much harder to spoof.

Currently it's very easy to make a fake MS login prompt, even to customize it with your company name and logo. If you fall for that, they have your PW, which probably at least works without 2FA on some random corpo websites like your time tracking or travel expenses or whatnot.

[ivewonyoung]

> why don't they ask for the 2nd factor first, and password second? Sounds like it would make it much harder to spoof.

How? First off if it's a TOTP without a notification the fake website can just ignore the TOTP input and always say it's correct and move to collecting your password. If it's a notification type 2FA, when you go to the fake site it can request a login with your username in the background which will send you a notification, you will enter the 2FA code and then password which the attacker will login with.

[semi-extrinsic]

> when you go to the fake site it can request a login with your username in the background which will send you a notification, you will enter the 2FA code and then password which the attacker will login with.

You're right, hadn't thought of this. But I wish there was a better way to verify that the login prompt is genuine, today it seems almost arbitrarily hard to be 100% sure of this.

[ivewonyoung]

The only way is a two way communication between the computer you're logging in with and the 2FA device. So that the computer can tell the device which website is requesting it, and the 2FA device will respond only if the website matches the website that the 2FA was originally registered with. Or have the totp key encrypted with the correct website url, so only the correct URL can decrypt it.

This is essentially what happens with a YubiKey so it's phishing resistant. It also happens with a passkey but thats just one factor since a unlocked stolen PC can login. For a smartphone as second you can probably have a similar setup by requiring a bluetooth or USB connection between the laptop/pc and the smartphone, but it comes with its own disadvantages. Can also work with QR codes I guess, but with the browser generating it from URL, not the site.

[semi-extrinsic]

Yeah, I should just go ahead and get a Yubikey already. Thanks for taking the time to answer.

[bayindirh]

Two reasons:

1. You shouldn't be reusing your password anywhere else anyway.

2. Microsoft corporate 2FA doesn't give you three choices, but wants you to enter the number from your keypad, unlike consumer 2FA, preventing flooding attacks and trusting that you'll tap the right one accidentally.

[semi-extrinsic]

1. In my scenario it is your corp admin reusing password across apps. See sibling comment on SSO tax response.

2. Yes, I know how the MS 2FA flow works. But why doesn't it have you enter number on device first, type password second? Seems like it would give users a better way of knowing the login request is legit?

[jpc0]

Database query is cheaper than multiple network calls and maybe even a database write?

If I send the password they need to hash then compare. Only then do they need to generate some form of random number - write to some store - send a notification to the users device - query the store from the users device - likely again hash an compare - send a notification to the endpoint signing in. To do that for millions / billions of users seems like it would be expensive compared to a hash + DB lookup.