[jabbany]

This is not a huge deal in practice and can be a good honeypot/alarm system.

Most services today have fairly low "lockout" + "notify" thresholds on wrong passwords so brute force spraying passwords is already out of the question.

Now, if someone fails the password check, clearly the user's current password is still secure so leaking that the attempted password was wrong to an attacker is not particularly helpful to them. If, however, the password is correct, then the attacker gets hit with the 2FA surprise. Assuming the great suggestion in this post is implemented (it really should be), the attacker now is stuck--abandoning the login or trying an incorrect 2FA could all trigger notifications to the user that their password was breached [re: the "Was this login you?" prompts implemented by major services after these situations]. Attackers would need to also solve the 2FA in some reasonable period to "disarm" such an alarm.

Real users who happen to fumble once or twice are also fine, since they won't be surprised about the login confirmation as it really was them.

[Jemaclus]

> Now, if someone fails the password check, clearly the user's current password is still secure so leaking that the attempted password was wrong to an attacker is not particularly helpful to them.

Maybe I misunderstand your post, but I think the parent comment is talking about leaking whether a password is correct and not whether it's wrong. (If I did misread your comment, apologies in advance and disregard the rest.)

The parent comment is basically suggesting that if there are two possibilities for password entry with two different experiences, then we may be telling hackers that passwords are correct, too.

Scenario 1: Password is incorrect and user sees "Oops, wrong password!" message.

Scenario 2: Password is correct and user sees 2FA prompt.

You are correct in that Scenario 1 doesn't help the hacker -- but Scenario 2 does! It tells them that the for username [e-mail], password hunter2 is a valid password. Even if they do hit the 2FA surprise and can't crack it, they can now take [e-mail] to any other website and try password hunter2, and any other site using the same credentials that is NOT secured by 2FA is now compromised!

There's also username leakage here. Imagine you had an OnlyFans account, and your coworkers or friends or parents were to put [e-mail] into it, and it simply said "Oops, wrong password" instead of something more generic. Now they know you have an OnlyFans account -- which, depending on your relationships, could be problematic, regardless of whether they actually accessed the account.

So to the parent comment's point, it is amazing how often credential leakage happens. And to OOP's point, we should go to 2FA every time, whether the credentials are correct or not. And the error messages should (generally) be more vague than specific, so as not to leak info unintentionally.

Does that make sense? I'm not sure I explained it very well, but I think the parent and I are making a different point than yours -- which is also a valid point, just not what we were talking about.

[rgbrenner]

That’s a tough decision. Going straight to the 2fa page immediately tells the attacker the account exists and does or does not have 2fa enabled… assisting them in narrowing down their efforts to less secure accounts and/or telling them which accounts they need to start phishing/etc for the 2fa code.

So you’re asking for the business to implement something that makes their own users less secure so that sites that don’t provide 2fa can be more secure. Maybe it would be better for those sites to improve their own security instead of asking others to compromise theirs to help cover for someone else’s lack of effort.

[jabbany]

But the moment the attacker knows the password is correct, you/the platform would also know the password is compromised assuming they cannot get past 2FA. There is an extremely limited amount of situations that end up with "passed password authentication but failed 2FA" and all the platform needs to tell them apart is a simple "Hmm, were you attempting to login?" email or notification.

The leak of the password's correctness here is ultimately not problematic as it acts as a tripwire and a surprise for the attacker. In fact the platform can take action on the user's behalf and lock logins with that password until the user confirms it was them trying to login via a separate channel (if you used Google 2FA this is what they do). It also protects accounts without 2FA because it becomes risky for the attacker to just try a password list they find. Maybe they're lucky and get in, or maybe the account has 2FA and you've just burned the password by trying it and alerting the user/platform about the compromise.

If it were the other way around with 2FA first, you would have no way of knowing your password is compromised somewhere. Even if the attacker knew the right password, the would not attempt to login unless they defeated the 2FA. Now you have no early warning system, and it becomes all-or-nothing: attacker get full access or they wait silently.

To sum it up: The login is no weaker if you put 2FA after password auth (same amount of compromises needed to get in). 2FA after password can leak password validity information for a short duration of time (on the scale of 15mins), but it also sets in motion an alarm that invalidates that password when an attack is attempted. 2FA after password also provides a tiny bit of extra protection to non-2FA accounts by letting them hide among the 2FA ones.

(Also, the original purpose of 2FA after password is to cut down costs for the platform back when SMS 2FA was the only 2FA. This is largely irrelevant today with TOTP and FIDO2 relegating SMS based authentication as the least secure option.)

[Jemaclus]

I think we're still talking past each other. In both of your comments, you seem focused on the particular site with the 2FA. I'm suggesting that that vector is irrelevant.

I'm not concerned about someone hacking this site with the 2FA tripwire, but instead about leaking password's correctness could impact usage of that password on other sites that use the same username/password and do not have 2FA.

Imagine if I go to Amazon and put in [e-mail] / hunter2 and then come up against a 2FA prompt instead of a password error prompt. Okay. I have a signal that suggests that hunter2 is, in fact, your password. I bail immediately. No point in randomly trying to guess a 2FA auth code.

Now I go to Walmart.com and put in [e-mail] / hunter2, and it works -- because there's no 2FA on Walmart.com and you re-used the password!

In this scenario, 2FA doesn't actually stop the hacker from compromising your accounts! It only stops this account with 2FA -- in that sense, you are 100% correct! -- but perhaps only temporarily, because they may be able to compromise other accounts that would allow them to eventually reset your 2FA tokens and get through.

If Amazon were to tell me "hey, someone failed the 2FA auth attempt, you should you change your password," then that's one thing. But we both know most sites don't do that.

[jabbany]

Password reuse is a very different issue. You should not be reusing passwords on accounts you care about period. 2FA isn't meant to protect against reuse (though it does help). If a password is reused your 2FA becomes just 1 factor.

This does not make reuse more dangerous either. An attacker with a leaked password list will try them against known sites anyways. If they wanted to try a leaked password against Walmart they'd have done it regardless of the 2FA signal. There's no reason to assume that if a password is (in)correct on one site that it would (not) be on another. The information of whether a password worked or not on a site means nothing to someone trying to hack your account.

Also 2FA sites do do this already. Google and Amazon both do this along with many others (and increasingly many). Also it does not have to force a password reset. A notification email about an attempt is sufficient, you can decide for yourself whether it was you or a suspicious attacker.

[randac]

This is fine as long as you notify the account holder based on both a failed 2FA OR just ignoring the 2FA prompt rather than making an attempt.

Personally I don't know enough to know if that's the case?

[williamscales]

I agree with the general thought process here, but there is a greater leakage: no service will allow you to create an account with an email that is already registered.

So all this discussion about how to handle the failed login is somewhat pointless.