[kevincox]

This is technically superior for things like TOTP but falls apart if not all users use TOTP.

1. Users who aren't using 2FA have a confusing box to leave empty.

2. SMS, Email and similar OTP codes should only be sent after the password is verified.

3. U2F requires the site to share which devices are registered which can only be done after the password is verified.

You may be able to make it work UX-wise if you separate username from auth information (such as a lot of sites do to support SSO auth). But even then it isn't clear to me if you should be leaking information about their 2FA configuration (especially their U2F device) list without a password.

[ezekg]

Your login form doesn't need to display an empty second factor input. Your server can send back a specific error code on first login attempt that can be used by the UI to prompt for the user's second factor, whatever that may be (or even give a choice, in the case of multiple second factor types).

For example, given this /login request to our server:

    POST /login
    Authorization: Basic Zm9vQGJhci5leGFtcGxlOmJhego=

Depending on the user's second factor, the server could send back a response like this:

    { "error": { "code": "TOTP_REQUIRED" } }

Then, depending on the error code, our UI could prompt for the second factor and we could send a new /login request:

    POST /login
    Authorization: Basic Zm9vQGJhci5leGFtcGxlOmJhego=
    { "totp": "123456" }

This flow can work for any type of second factor, not just TOTP. It also works for good and bad passwords, and doesn't leak any information (well, other than the fact the user exists, but that road introduces a lot of other UX issues.)

[kevincox]

Good point.

It does leak a little information. It leaks the type of 2FA the user has configured and a list of devices for U2F (since that needs to be provided to authenticate). But that is likely acceptable.