Multi Factor and order of authentication [duplicate]

Question

I'm questionning the design and architecture around 2FA/MFA controls while authenticating to services and servers.

On major platforms(*), the end-user is:

• first prompted for credentials (username/password) - something you know
• then prompted for the second factor (Push, Time-based token, or Hardware keys) - something you have

This design allows a hacker to attack/test the password (the first factor). If a password is successfully compromised (guessed, brute-forced[dict+perm] or sniffed/captured), the second factor would then hopefully prevent malicious access, however the successful password can then be used on other services where 2FA is not enabled (credentials stuffing).

Why is the time-based token/push or HW key not used as a first factor and the password as a second factor?

1. Is there a specific reason for this FA order (more intuitive to end-users?)

2. Other controls are in place to reduce the risk associated to passwords.

3. Is it because the developers or security specialists are opting not to redesign the initial login process (risk retention/acceptance)?

(*) examples include Twitter, Facebook, LinkedIn, Google, microsoft, dropbox, Box Sync, most banks portal...

Answer 1

The reason to prompt for the password factor first instead of the second factor tends to be either to prevent harassment of the user or to reduce costs associated with usage of the 2FA service.

For example, with Twitter they send a push notification to the user's device for login verification. If it didn't require the user's password first to authenticate them then attackers could spam their device with login verification requests all day long. Or if they used the SMS option the same thing would happen with texts to their phone, plus I believe Twitter has to pay SMS gateway providers for each text they send. This would disincentivize users to enable 2FA.

There are 2FA factors which can be implemented so they aren't intrusive to users or expensive to providers, like TOTP/HOTP. If a system prompted for the one-time password token along with the username they could verify this first before asking for the user's password. From what I've heard this is actually done with Norwegian BankID. Hackers can still annoy the authenticating site by flooding it with username/OTP guesses, but the site can also deal with these problems in a similar way to password guessing attacks.

Authentication based on WebAuthn would also work well with a stronger factor first design, or without a second factor password at all.

I assume there are probably some usability issues with switching the order. You would have some people typing their password into the OTP field if you start prompting for that before their password. That could lead to some account lockout issues. However, you could probably reduce this to a manageable level with training and effective UI design.

I also agree with you that there are just traditional app design issues influencing some of these decisions. You would likely need to ask a user for their username alone and then determine what next step to prompt them for (password or other factor) based on a lookup of their 2FA enrollment status. Google does this already, but I haven't seen this design pattern implemented a lot by other sites yet. With time we may see others adopt this same approach.

Most sites are primarily concerned with preventing account intrusions against their users and not as much about whether an attacker happens to figure out a user's password can work elsewhere. After all, the attacker could still actually try their same password guesses against the user on all those other sites. Beyond combating this with normal password guessing prevention controls, I don't imagine many administrators spend time worrying about that possibility.