Do 2FA sites leak info by confirming a correct password guess?

Question

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?

Answer 1

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:

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

2. 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:

1. 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.

2. "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.

Answer 2

I think this is a non-issue. Multi-factor authentication isn't about preventing someone to guess your password, but to prevent anyone to sign in on your accounts.

Answer 3

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.

An attacker isn't going to try guessing a password on Google that they aren't also going to try for the bank or facebook or the like. Just because it's now been given away that it is a valid password puts the attacker no closer to compromising any other accounts. The guessed password needed to be from a crib of high probability guesses, because a true brute force will never work on a live system.

If you could demonstrate that sites using 2FA have worse anti-guessing algorithms (I would bet they are at least as good if not better) compared to sites that don't offer 2FA, your point would be valid since an attacker could abuse one and pivot toward the other. In reality the opposite is likely true, sites investing in 2FA are also investing in anti-guessing systems at the same time.

Answer 4

In theory, yes, this is a possibility (provided the site implementing 2FA doesn't have any rate limiting or fraud detection of any kind, as pointed out by the other answers).

In practice, there's the usability factor to think about, too. Imagine you built a login form that prompts a user for 2FA on every login attempt, only telling the user the attempt was unsuccessful after the 2FA step, and never telling them whether it was the password or 2FA token that was invalid.

2FA is already a giant pain in the neck to start with - every time I log in, I have to not only type in my username and password, but find my phone (which might be in another room), unlock it, go to my home screen, find my 2FA app, and find the right site in the list. Then, the code is inevitably five seconds from expiring, so I have to either wait for a new one to come up or try to type it in super quickly before it expires.

(2FA systems that use SMSes or push notifications are better in this regard, because they come up on my smartwatch - or, in the case of a user that doesn't own a smartwatch, their lockscreen. In the scheme we're considering, though, that would allow a user to annoy me with endless notifications/SMSes so long as they know my username, because they don't have to get my password right to trigger a 2FA attempt. I've also heard that in some countries, phone carriers charge you for receiving SMS messages, so in those places this sort of thing would be even worse on users.)

If you make your users go through all of that twice when they get their password wrong, the whole process will become much more painful, and you might even wind up with less people using 2FA as a result, making your users less secure on average.

Answer 5

For systems where 2FA/MFA is "optional" such as Gmail or Outlook.com, the service has to balance the hassle factor of using the 2-factor method and the security it brings to their site. In a perfect world, users would have unique, complex passwords for every site, and always use 2FA when available, but in the real world, you're right - users will have the same password on a dozen sites, and a 2-factor mechanism that doesn't automatically lock the account and notify the user after a few invalid login attempts in a relatively small window could lead to a situation where the attacker patiently tries a few likely guesses until they get to the 2FA prompt, at which point they know they've got a valid username+password combination. With all the highly-public password database compromises on large sites (such as LinkedIn, among many others) that use your email address as your login, then an attacker can logically guess a user's password relatively easily if the user never bothered to update other sites, but just the one that was "cracked".

For security-critical apps (such as one of several I work on), the login prompt requires username, password, and 2-factor value all at once, and it's an "all or nothing" authentication, and we don't tell you WHY your login failed, unless it's because your password has expired (which assumes you entered the correct password, but it's just going to require you to change it and enter that again with another 2FA value to actually gain access to the application). That application has a "captive" user base and the 2FA is required by policy, so it's not directly comparable to the "2FA-optional" sites you mentioned in the OP.

Fundamentally, though, I agree with the comments above that a "token-on-demand" is safer than an "offline" token (like RSA or Google Authenticator) if you're going to do the 2-step authentication because the user will know right away that someone's trying to access their account by virtue of the unexpected SMS messages, either "wrong password" or a valid 2-factor string in the event the attacker gets it right. If the site ONLY sends the SMS 2-factor value on successful login, then it's useless for the very point you mention, at letting the user know BEFORE the attacker actually gets the correct password. The user would only get the valid 2-factor string when the attacker had the right password. By that time, it's probably too late, and the attacker is already off trying that same username+password combinations on other sites that don't have 2FA and the user would have to be at a computer and scramble to change every password on every site they use it on, which if they're reusing the same password everywhere, is pretty much impossible because they won't remember them all.

Ultimately, it's up to the individual implementation as far as how damaging a 2FA can be to other sites used by the same user. Best case, it's an all-in-one login like I described, where the attacker would have to also somehow have their 2FA device or "magic string" (initialization token for something like Google Authenticator), and if they've got that too, the user's already been well-compromised.