2

My employer's login flow asks for a username, then a 2fa, then a password. They do it this way because they fear someone could try to brute force passwords and create a denial of service attack by locking out all our accounts. This flow breaks my password manager and because I've not seen a similar flow elsewhere I'm betting there are compelling reasons not to do things that way.

What are compelling arguments for the traditional flow of username -> password -> 2fa?

Improve this question
4
  • 1
    Please explain more. This is how almost all systems that offer 2FA work, in my experience. Examples are Google, Yahoo, Hotmail, Apple, etc. They all ask for username and password before prompting for a 2FA code.
    – Jesse P.
    Aug 29, 2018 at 13:11
  • 1
    @JesseP. The question says username->2FA->password, which is different to Google etc.
    – Matthew
    Aug 29, 2018 at 13:32
  • @Matthew Between the article title and the body, I mixed up what was being asked. My bad.
    – Jesse P.
    Aug 29, 2018 at 13:38
  • @Matthew I like the reasons and explanations given on that article and it seems like this really has no known negative consequences beside advertising that 2FA is enabled or disabled on any account, to allude to which accounts are easy prey.
    – Jesse P.
    Aug 29, 2018 at 13:58

3 Answers 3

Reset to default
3

I actually like your employer's flow too, provided that users have a passive 2FA method like code generator apps, Yubikey, etc.

If your auth system allows users to set up active 2FA methods like Email / SMS OTP or push notification to their phones then there's a totally unrelated reason to put 2FA after password: not because it protects the account better, but because an attacker can out-of-memory a phone that's receiving thousands of SMSes or push notifications. Not to mention that some mobile carriers charge for incoming SMSes.

See my more detailed answer to the same general question here.

Improve this answer
2

I actually like the flow your employer has better, to be honest. If you can't get past the code entry you most likely would never get past the password prompt (which is what would lock the account out, typically). So, this flow actually does seem to prevent it from getting that far.

I think the reason everyone uses the traditional flow is due solely to the fact that their authentication method is already in place and they're adding 2FA as an after-thought (additional feature) rather than having it built in from the ground up to implement it in the same manner as your employer, or they simply haven't thought about it in the same way to see the benefit.

Improve this answer
5
  • "never get past (to?) the password prompt (which is what would lock the account" Presumably, there's no need/point in locking-out due to failed 2FA attempts because the correct code is constantly changing, so you can't brute-force the response like you could with a password.
    – TripeHound
    Aug 29, 2018 at 13:51
  • @TripeHound It's not missing a "to". It clearly says "past the code entry prompt" and then "past the password prompt". Please clarify what you were suggesting instead.
    – Jesse P.
    Aug 29, 2018 at 13:53
  • @TripeHound Yes, that's what I was saying. If you can't get past the 2FA prompt, there is no [theorietical] need to lock out the account because you aren't attempting password entry (incorrectly) - you can't even get that far because you're stuck on the prompt before it.
    – Jesse P.
    Aug 29, 2018 at 13:54
  • "Please clarify..." The "to" was intended to replace "past"... if you can't get past the 2FA prompt, you will never get to the password prompt (and therefore never have a chance to enter any password, correct or otherwise). Using "to" sounded better (at least to me).
    – TripeHound
    Aug 29, 2018 at 14:02
  • @TripeHound Oh. I see what you meant. What I was saying is that if you can't get past the code prompt you would never have been able to get past the password prompt if we were dealing with the traditional flow instead (password first). So, since bad passwords lock accounts out, asking for it AFTER the code prevents lockouts by brute-force attempts. If my previous statement were solely about the custom flow, yes, "to" would be more appropriate.
    – Jesse P.
    Aug 29, 2018 at 14:04
0

Both options are equally secure as far as I know. But I can't agree with @Jesse P. answer.

Both factors should lock the account. Lets imagine that an attacker has obtained the victim's password (Maybe through a data leak, phishing, etc), if the second factor does not lock the account the attacker can attempt bruteforcing it, even if it changes through time, until it's able to access the account. This is not affected by the order in which the authentication factors are entered.

The only possible risk in this scenarios - if the implementation is correct - is account enumeration from error messages or time based for the second factor.

As a side note, there is a third possibility in cases where all the users must have a second factor and all of them have the same kind, that is asking for both at the same time. Special care in this case to not disclose which factor failed

Improve this answer
4
  • I agree that from a pure security standpoint, both factors should lock the account. From a usability standpoint and problem prevention standpoint, locking the account for failed 2FA attempts could be problematic. Since the code changes every 60 seconds, typing in a code in the middle of a change could result in a failed attempt because it may timeout the previous code immediately (most systems I've seen do still let you type in the previous code a few seconds after a new code was generated, to account for time sync issues) and be counted as a failed attempt.
    – Jesse P.
    Aug 29, 2018 at 14:39
  • Also, because the code does change so frequently, the chances of someone successfully being able to try all possible combinations in that 60 second window, after accounting for page load between attempts and possible rate-limiting, are HIGHLY unlikely.
    – Jesse P.
    Aug 29, 2018 at 14:40
  • Unlikely or not this protection has to be present. Imagine that an attacker has obtained the victim's password. If the account is not locked out after a few attempts there'd be nothing preventing the attacker from bruteforcing the 2nd factor, even if it changes every 60 seconds. Given infinite attempts to guess 1 in a million is not negligible. Furthermore, this measure does not affect usability as an attacker should fail multiple times, while a user should fail 1 time top if s/he is in posession of the 2nd factor
    – Mr. E
    Aug 30, 2018 at 0:16
  • I already said that from a pure security standpoint I agreed. As a compromise to usability, to prevent lockouts and thwart attacks, possibly using an increasing rate-limiting mechanism would be a better to deal with failed attempts. 1st failed means 5 seconds delay for the next attempt; 2nd fail means 1 minute delay; 3rd fail means 10 minutes; etc. It would keep going up and up so long as you fail.
    – Jesse P.
    Aug 30, 2018 at 0:24

Not the answer you're looking for? Browse other questions tagged .