Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question

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.

share|improve this answer

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.

share|improve this answer
Interesting, and this gives the impression that consecutive method is insecure. However, it really makes a difference when you're talking about millions or billions of possible passwords. – SPRBRN Apr 18 '14 at 7:31

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:

share|improve this answer

"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.

share|improve this answer
I'm talking about an XHR request with the username. I'm not trying to reduce the number of requests. I'm trying to improve the user experience while maintaining the same level of security. – anthonyryan1 Apr 10 '14 at 7:54
I guess it depends exactly what risk you're trying to overcome - you need to be careful you're not avoiding one risk at the expense of another. For example, you could be preventing username/password verification without a token, but enabling easy username/2FA usage enumeration. – tenorkev Apr 10 '14 at 17:40

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.

share|improve this answer

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.

share|improve this answer

For internet banking 2FA, this is the reason I could think of why they make a 2nd form. They want to reduce the load on the database and processing for performance issue.

For internet banking our 2nd factor is normally a generated key with some devices and the key is normally changed every minute / X minute. Imagine on the server they need to re-generate and update the list of keys on every users every minute in the database. The amount of processing workload required for the database will be having very high load as they need to re-generate and store the new key every minute.

To solve this issue, they just create a 2nd form so the 2nd factor key don't get generated and re-update to the database every minute. The key only get generated and update only after the individual user could provide a successful login with their username and password. So most probably their 2nd factor authentication will be something like

  • Checking user input key against the server generated key. The time difference shouldn't be more than X minute, if not return login fail.


  • Checking user input key against the server generated key and the generated key is the database should not be NULL. The generated key in the server will be updated to NULL (expired) after X minute.

And only if the 2FA authentication are having correct key and password, they will return you an authentication token (e.g. a cookie) to store your login session.

share|improve this answer
This is not how OTP tokens actually work. The server stores a seed associated with each device, and when an OTP is submitted, the server simply computes a function on the seed and (depending on whether you're using HOTP or TOTP) either a counter or the a timestamp. – Stephen Touset Apr 10 '14 at 1:36

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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