2 Add comment about SMS/push 2FA
source | link

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 as it isto 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.

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 as it is - 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.

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.

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.

1
source | link

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 as it is - 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.

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.