Can Simultaneous Logins Occur When Two Users Have Both Pieces Of Two-Factor Authentication Information?

Question

In a hypothetical situation (say a screen capture program or rootkit, where, incidentally, a password change will not make any difference) where an attacker has both your password, and sees the two-factor response upon logging in with that password (whether it's via SMS or a more robust system like iCloud to iPhone Two-Factor), is there a situation where both users, having both password and two-factor, can log into a system at the same time?

For the sake of the example, let's use Apple's iCloud system, logging in on a Macbook, receiving a two-factor code on an iPhone (not via SMS, via their cloud-based two-factor system). Both the laptop and phone are rooted, so both are visible. Can the login information be used to log in in more than one place simultaneously?

Answer 1

It depends on the type of the OTP method and implementation details. Whereas [RFC4226][1] (the counter based OTP) can be understood to forbid reuse, as it says:

the server's counter value is only incremented after a successful HOTP authentication

But that may not be a guarantee that there is no time window that the same HOTP token will be usable - multithreaded authentication servers, with concurrent database access may overlook this detail.

It is also describing that:

RP3 - P SHOULD be implemented over a secure channel in order to protect users' privacy and avoid replay attacks.

Which implies they don't consider it the property of the protocol to protect against reused tokens!

Similarly, for time based OTP [RFC6238][2] explains that it's a good protection against attacks to reduce the time window when a token is valid. But it is mentioning the token is consumed, which, to some may imply it cannot be consumed again.

First, a larger time-step size exposes a larger window to attack. When an OTP is generated and exposed to a third party before it is consumed, the third party can consume the OTP within the time-step window.

I, personally do not think a copied second factor should be valid, but this is not necessarily what the standards say, so there may be variations on how this is interpreted. Other 2FA vendors may not even adhere to any of the standards, and may have stricter or looser requirements. Let me also note that it may be difficult to implement a reliable method of locking out all but the first use of a token within widely distributed networks, for all cases.

Update: now that I think of it, I can see two additional ways of preventing access with duplicate OTPs - one is at the preparation: making sure there's only password login out there that is in progress of accepting an OTP until the authentication timeout. The other is invalidating the already granted session, in addition to the duplicate one. This can be easy in a web-based service, but not as convenient with a computer shell access.

Also to be considered that you can't be sure the valid user is the first one, so it can be a hindrance for the them as well. In the case of true MITM, the attacker can even stop the genuine attempts by them so that there can't even be a notification over the same channel.

As you can see, it's not as simple of accepting or not accepting the duplicate OTP - you need to consider the user of the service, how they can get into this situation and how they will be the least harmed, or best served. Perhaps this is why the standards won't discuss these details, and leave it up to you.

[1]: https://www.rfc-editor.org/rfc/rfc4226 RFC4226-HOTP [2]: https://www.rfc-editor.org/rfc/rfc6238 RFC6238-TOTP

Answer 2

Having two login sessions is possible, but it will require two instances of both the first and second factors.

The second factor is generally a one time use code, that will expire after use. It may also time-out after a specified amount of time if not used

For example; if the he first factor is a username/password, that will be the same for both login sessions.

If the second factor is a token, in form of a unique 6 digit code. Both logins will need the common username/password and their own specific instance of the unique 6 digit code

This is of course a generalisation and different systems will have their own nuances.

Incidentally, in a very non-scientific experiment I tried using the code from one Google login attempt on a separate login attempt to see if the code was portable between sessions and it was successful.