[3np]

One problem with the two-step approach of only prompting for 2FA after successful auth is it leaks a lot of information - an attacker can confirm that they got the right password, or even just that the account exists and has 2FA enabled.

For TOTP-based 2FA, it would ideally prompt for all three (username/password/TOTP code) immediately, not indicating which part of auth failed.

This may not always be desired, for example when TOTP is just one among several 2FA options.

In those cases, at the very least always prompt for 2FA for accounts that require it, regardless of if password auth succeeded or not. Don’t tell the user if it was the password or TOTP code that failed.

[rpadovani]

> In those cases, at the very least always prompt for 2FA for accounts that require it, regardless of if password auth succeeded or not. Don’t tell the user if it was the password or TOTP code that failed.

This still leaks that the account exists and has TOTP enabled tho.

You have to choose if leaking the correctness of the password, or allowing DoS of a login, unless all the accounts have the same MFA.

[duskwuff]

> This still leaks that the account exists and has TOTP enabled tho.

You could mitigate that by prompting for an OTP code on a random but stable subset of nonexistent accounts -- for example, by hashing the provided username with a server-side secret and requesting an OTP if the hash starts with a zero.

[3np]

First time I see this idea - I like it!

[3np]

Yes, maybe I should have made that compromise more clear. The alternative I see would be to enforce some form of 2FA for all accounts and always prompt for 2FA. Depending on the system it may make sense.

It’s still way better than leaking a successful password auth.