Here's my relatively layman's view of the issue.

Many websites tout multifactor authentication (MFA) as an enormous boost to the security of users' accounts, and it can be if implemented properly.

However, it seems that some sites will only prompt the user for their MFA AFTER they enter their password correctly.  I've only tested this with gmail.com and outlook.com, but given that these are two huge email providers, I imagine they're only two of many perpetrators.

The reason this is (at least on the face of things) such a huge security flaw is that it can allow crackers to guess a user's password until they're presented with the prompt for MFA, at which point they know they've got the user's password.  It seems like websites will brush this off, saying, "But since the user has MFA, the cracker can't get into their account."

What they seem to forget is that the user likely has accounts on other websites, and quite possibly uses the same password for that site.  So now the cracker may have access to all the user's accounts across the web, many of which probably don't have MFA implemented, leaving the user completely vulnerable to attacks.

Are there any flaws in my argument or assumptions that would make this a non-issue?  If not, then why do huge companies like Google and Microsoft not fix this issue?

If I'm understanding your question properly, the attack you are proposing is to brute-force passwords against a server like this, then once it shows you the MFA screen, go try that password on other websites that this user has accounts on.
This is a great question! Good find! But you seem to be overlooking two points:

This is no weaker than not having MFA, which also confirms the correct password ... by letting you in.

No hacker in their right mind will try brute-forcing a password against a live server which typically rate-limits you to like 5 guesses per second. Or in the case of the big providers like GMail or Outlook, have complex fraud-detection systems that do auto IP-blocking of suspicious activity. 99.999...% of the time, password brute-forcing is done against password hashes stolen directly from the database on which you can guess (m|b)illions of passwords per second.


So while I agree with you that there is the potential for some data leakage here, I think the risk is minimal, and far outweighed by the user inconvenience of having to fumble with their OTP fob just to find out that they typo'd their password.

Update addressing comments since this has become a hot network question:
There are two types of Multi-factor authentication (aka "2FA" or "MFA") that really need to be thought about separately:

SMS or Push Notification 2FA: when you get to the 2FA screen it sends a code to your device that you have to type in. For many users, this is probably the only type of 2FA that you've been exposed to. The attack described in the question will not work in this case because the user will receive a 2FA code they did not request and they'll know something's wrong.
Moreover, doing the 2FA step regardless if the password is correct is actually harmful it this case because:

An attacker could potentially cause the user to get a huge monthly data / SMS bill, or crash their device by filling its memory with notifications.
It also leaks which users have 2FA enabled, and which are easy targets.


"Offline" 2FA using code-generator tokens, apps, or public-key enabled smart cards / USB sticks. This is the kind of 2FA that government, military, and corporations use. So while it's less visible to end-users, it's by far the more important type of 2FA because of the value of the data it's protecting. In this case, there is no "built-in" notification to the user when an attacker gets to their 2FA screen. And usually all users are required to use 2FA, so there's no harm in leaking which user have 2FA enabled, because it's all of them.


Imagine this scenario for Case 2: a corporate VPN that sits on top of the Windows Active Directory. Public-facing VPNs get hammered on all day long by password guessers, so there's nothing unusual about those logs. But if I can have the user's password confirmed by the VPN's 2FA screen, then I can walk up to their laptop and log in confident that it will not lock out the Windows account - which would certainly get noticed by the user / IT. The question correctly points out a security hole that the pattern of "got to the 2FA screen and entered nothing / entered something incorrect" should certainly be flagged as more severe than your standard "incorrect username/password" and should notify the end-user to retire their password.
