Why not ask for a password and 2-factor token at the same time?

Question

I have observed a number of web-based login forms that offer 2-factor authentication do token entry on a second form after validating your username and password.

Is there a reason not to ask people for their 2-factor authentication token at the same time as their username and password?

A login form could detect a username that has 2-factor authentication enabled before they complete the login and present them a token-entry box on on the login page.

This would leak whether any given username had 2-factor authentication enabled, but wouldn't confirm a valid password without a valid token.

Answer 1

Many OTP systems allow you to receive an OTP by SMS/email. So the system has to know when to send you an OTP.

You might suggest that there could just be a "request OTP" button next to the form. But then anyone can repeatedly click on the button, meaning that you will receive a huge amount of spam email/SMS.

You might suggest fixing that issue by limiting the rate of OTPs. But then I can cause you a denial of service by requesting your full quota of OTPs so that you can't log in.

A simple solution to this is to only send an OTP to a user that has provided a valid password.

Answer 2

I do not see any security issue in asking for the password and a second factor (token/biometric) at the same time.

In fact this increases the security of the system, but it might affect the usability (user experience) of the system. How is that?

Let us say that the system take the two-authentication factors (password and OTP) at the same point and test them. if they both match/pass it allow access otherwise it deny access.

let us assume there are 100 possible passwords and 200 possible OTP codes.

If you ask first for the password at one point and then when a valid password received you ask for the OTP then an attacker need to try 300 times (100 + 200) to break into the system.

But if you ask for the password and the OTP at the same time the attacker will need to try 20000 times (100 * 200) to break into the system.

Now, from usability point if the user entered wrong password or OTP code the system will not tell him exactly what went wrong and he might keep doing the same mistake, for example entering the wrong password because he thinks it is correct, while the actual problem with his OTP token or the other way around.

Answer 3

There could be a number of non-technical reasons, possibly a driver would be performance because it reduces load to some processing on the backend that doesn't need to get called.

Another possibility may be to make it harder to setup a phishing website. You now need to program multiple pages. Also, if you only show OTP when there is a successful username+password (something you know authentication) it can make it hard to create the phishing site and provides more pages for the user to notice. Security images are often known as being of minimal value because the process is often username, then show security image (e.g. SiteKey), then password. However, if you only change this with two-factor to be username->password->security image->OTP this makes creating a phishing site more complex, though still not impossible since the phishing site can emulate a user session to the real site with the username and password.

The following questions address spreading out a logon over multiple pages in general:

• What are the benefits to a two-page login system for a webapp?
• Two page logon to prevent accidental password exposure

Answer 4

The reason we decided not to ask for two-factor auth keys at the same time had nothing to do with security. It turns out asking for an one time password at the same time as the normal username and password can cause autofill misbehavior with various plugins, scripts & browsers.

This is a UX reason rather than security, but substantial enough to probably be the reason for this standard.

Answer 5

"A login form could detect a username that has 2-factor authentication enabled" - How?

In order to do this, the page would either need to send another request to the server, including the user name (which seems to be what you're trying to avoid), or the page would have to include a list of all the usernames with 2-factor authentication enabled in the body of the original login page (not a good idea).

There are advantages in this specific case for keeping whether 2-factor authentication is enabled a secret until the password has been entered correctly - particularly in the case of tokens sent by text message, for example. If a 'baddy' manages to find your username and password for the site, they may not know whether 2-factor authentication is enabled. This means they may try logging in, and cause the service to send you a text, alerting you that your password has been compromised, and preventing them from being able to access your account. If they can tell immediately whether your account has 2-factor authentication enabled, they wouldn't take that risk.

Answer 6

I would argue this is a limitation of the type of authentication used. A push, dial-back or SMS-based systems (eg: Duo, PhoneFactor) is really only one factor: possession of the device, therefore the user must also enter the something you know first which kicks off the request. Since each request cost money (either to you or the service or both) they want as few as possible.

Other systems include both factors in one. With Securid the PIN is appended to the OTP and entered once. With WiKID, the PIN is entered into the token to get the OTP so only the OTP needs to be entered.