8

So in most websites on login page you have to input username and password for e.g. Facebook where you input username and password and then submit form. Other websites ask you each separately e.g. Google where you input username and submit, then password and submit etc.

In case the second scheme is used - username then submit etc. Why not use the SMS code first?

My idea is that this would prevent users from guessing or bruteforcing the password, which commonly is used on other services like email, which then often can be used to unlock account from SMS authorisation.

Another reason is that this would provide the user straight with information about login try.

Edit: I realized that I did not mentioned that 2FA is not required, but rather optional, similarly to facebook or google.

I also would like to assume that the 2FA process is not flawed itself - the user can not set invalid number and the number is checked upon setting. The number would been checked by sending test OTP which would be required to confirm that the number is correct.

  • 6
    If it's SMS 2FA you'd get spammed with messages if someone brute-forces your login. – Arminius Apr 8 '17 at 14:36
  • While this is a valid point @Arminius, what is the chance of attacker actually trying to bruteforce the code. Especially if after the code would be generated new after wrong code – vakus Apr 8 '17 at 14:57
  • for clarity I decided to add on to my previous comment. Even if a hacker would be trying to brute-force my SMS code, I (personally) would prefer to get thousands of SMS messages than get one SMS when the attacker already knows my password, and likely have access to my email address, which then can be used to override (usually) 2nd factor, with "I dont own this phone number anymore". I know that I personally could avoid using the same passwords, but this would not be the case for most people – vakus Apr 8 '17 at 16:31
  • 1
    @vakus: I would rather not get spammed with SMS, and personally I would genuinely love it if I could get an SMS every time a hacker was able to figure out my password. Why would you not want that? – John Wu Apr 10 '17 at 13:25
  • There is one major point that I haven't seen addressed. It comes down to the control point saying "Sorry, wrong username". If that statement is true, it tells the attacker to try another userid. If the application says "Sorry, that didn't work" it makes it harder for the attacker to determine WHAT was wrong. Same thing with passwords and OTP codes. If you ask for a password first, the attacker can't discern as easily if they use OTP yet. It's minor, but defense in depth stipulates that adding small security controls still improves the overall security, even if marginally. – 0xSheepdog Apr 10 '17 at 17:35
10

TL;DR Security is hard and making even small changes to the way security protocols work can open up unexpected attacks. While it may seem at first glance like putting the 2FA before the password helps to protect the password, it actually opens up much worse attacks. Let's have a look!


The problem we're trying to solve

According to your question, the problem you're trying to solve is password brute-forcing. This is a bit of a red herring because people crack passwords against stolen or leaked databased of password hashes, people don't brute-force against live servers because things like rate-limiting already do a pretty good job of solving this problem. That said, let's take a look at different types of 2FA and what would happen if the 2FA went before the password.

Code generation Apps

aka Time-based One-Time Password algorithm (TOTP), for example, the Google Authenticator:

Google Authenticator screenshot

I agree with you that I can't, off the top of my head, think of a reason why putting this first would weaken the authentication protocol.

Notification Apps

Some 2FAs are designed to pop up a notification on the phone rather than hiving you type a code, for example the Blizzard Authenticator:

Blizzard Authenticator screenshot

Doing what you suggest of putting this before the password would actually be dangerous because it leads to a denial-of-service attack: the attacker hammers a user's account so that there are near-constant notifications on their phone, either preventing them from being able to use their phone, and / or forcing them to disable the 2FA in order to make the notifications stop (and weakening their account).

SMS Codes

aka sending a One-Time-Password to your phone by SMS.

This has the same problem as Notification Apps in that it leads to an obvious denial of service attack, but it's worse because in some places, phone carriers charge for incoming SMSes, so the attacker can force the user to pay huge cell phone bills.

Summary

Of the three types of 2FA apps I mentioned, your proposal is neutral for one, and detrimental for the other two.

Also, putting the 2FA step first would advertize to attackers which user have enabled 2FA, and which have not. Basically telling them who the easy targets are.

Finally, the notification and SMS based 2FAs server another valuable purpose: an alarm to tell you when your password has been cracked. If I get a 2FA notification that I did not expect, it's time to change my password.

I like that you are thinking outside the box and challenging the way things are. Security is hard, but don't be discouraged from asking more questions, this one was fun to answer.

  • Speaking about thinking outside the box, thanks for covering other similar scenarios, and your answer pointed out to me, thing that I never thought of - phone carriers charging for incoming SMSes – vakus Apr 10 '17 at 14:53
5

It's so users who make a mistake don't wait indefinitely for an OTP that will never come.

Imagine the workflow if the one-time password (OTP) came before password. It would look like this:

  1. User enters user name
  2. System looks up user name to find mobile phone number

    a. If user name is valid and phone number exists, system sends OTP

    b. If neither one exists, system sends nothing

  3. Either way, system displays "We've sent a one time password to the mobile phone number associated with your account."

Why "either way," you may ask? Why is the message the same in both cases? See OWASP authentication cheat sheet which tells us:

An application should respond with a generic error message regardless of whether the user ID or password was incorrect. It should also give no indication to the status of an existing account.

Correct Response Example

-"Login failed; Invalid userID or password"

Incorrect Response Examples

  • "Login for User foo: invalid password"

  • "Login failed, invalid user ID"

  • "Login failed; account disabled"

The reason for the generic message is to avoid providing any signals that a hacker could use for user ID farming.

Now let's continue our workflow.

  1. If user entered a valid user ID that has a phone number, she receives the OTP and can enter it.

  2. If user did not enter a valid user ID, or entered a user ID that has no phone number associated with it, the user waits indefinitely.

So now we see the problem. If the user makes a mistake, the system can't tell her she made a mistake, and she will have to wait for the OTP indefinitely. This is different from password authentication, where the feedback is immediate.

This whole problem goes away if the password is checked first. Once the user is authenticated with the first factor, we have already established that the user ID is valid, and it is OK to tell them if they never set up a phone number on the account.

Other use cases are affected too

These other use cases also become poorer UX, or are awkward to implement due to security requirements:

  1. User has more than one phone.
  2. User has switched phones recently.
  3. User has misremembered his user ID
  4. User is in a locked out status
  5. User's SMS inbox is full
  6. Carrier restriction, e.g. SMS limit exceeded or customer in collections
  7. Phone is lost/stolen
  • Thanks for an answer, however I have feeling that you are talking mostly about flawed 2FA, whereby user can set 2FA without setting his/her phone number, or whereby the system does not check if the number is valid upon setup. For example on facebook or google, when setting up 2FA, the system checks whatever the number is valid, before enabling 2FA, and whatever there is any. I believe that I should add to my question that the 2FA is not required but optional and to assume that the 2FA is not flawed (can be enabled without valid phone number). – vakus Apr 10 '17 at 12:21
  • No, your feeling is incorrect. My feeling is that you have not spent much time developing 2FA systems. Even an "unflawed" 2FA would still need to handle the scenario where a phone number is not available, e.g. if the device is deactivated by a CSR, bounces messages, or user has opted out the number by replying to the SMS directly from the device. But set that aside if you want; the more important scenario is when the user ID is not enrolled in the system at all. – John Wu Apr 10 '17 at 12:52
  • SMS OTP isn't secure, and so we shouldn't really talk about codes "being sent". – Awn Apr 10 '17 at 13:17
  • What should we talk about instead? – John Wu Apr 10 '17 at 13:22
  • @JohnWu I will admit that I never generally developed any 2FA system, but I was wondering whatever it wouldn't be more secure other way around – vakus Apr 10 '17 at 14:47
1

That's for spamming reasons.

Doing so allows an attacker to iterate over usernames (mainly, these are publicly available or very easy to guess) so the website will send a lot of useless texts/mails to everyone. Website would then certainly be blacklisted as "spammer".

And this cannot be secured, except by shutting down all logins for few minutes (if you keep spamming only one account, as said in a comment, then you could refuse to send another OTP if one was already asked minutes ago, but this cannot be done website-wise).

Asking for password first blocks this kind of attack, since you would have to know everyone's password too.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.