4 ms·

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 passw

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 4y ago
> 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 jabbany@email.com, password hunter2 is a valid password. Even if they do hit the 2FA surprise and can't crack it, they can now take jabbany@email.com 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 jabbany@email.com 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 4y ago
  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.
- williamscales 4y ago
  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.
- jabbany 4y ago
  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 4y ago

> 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 jabbany@email.com, password hunter2 is a valid password. Even if they do hit the 2FA surprise and can't crack it, they can now take jabbany@email.com 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 jabbany@email.com 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 4y ago
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.
williamscales 4y ago
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.
jabbany 4y ago
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.)