4

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?

  • 2
    I think the OP is asking whether the same 2F token can be used twice if the login is simultaneous. I would think it's the main purpose of 2FA is to make sure the token will be needed to log in, and useless after. How long after, it should not matter, 1 minutes or 0.001 seconds - it should be marked used, and not allow a second authentication (regardless of who was first). But it's an implementation detail that's hard to test for the corner cases. – chexum Dec 24 '15 at 9:58
6

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://tools.ietf.org/html/rfc4226 RFC4226-HOTP [2]: https://tools.ietf.org/html/rfc6238 RFC6238-TOTP

  • It should be up to the validation server to make sure that the same token is never allowed to be used twice. Otherwise the whole "One-Time" part of "OTP" is no longer true. – mricon Dec 24 '15 at 17:54
  • @chexum I've thought about your excellent answer several times, including the updated part. I was wondering, is there a way to find out what protections certain services have in place, in this regard, such as iCloud and Google Apps? – rcd Jan 8 '16 at 23:58
  • I just tested, the 6 digit second factor with two concurrent logins on two unrelated machines. The second attempt with the same good code (both using the right password, and asking to use the authenticator app), Google just responded "Wrong code. Try again." – chexum Jan 10 '16 at 11:02
5

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.

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.