5

Note that I'm not talking about systems like Authy, where you can log in to your account on multiple devices and sync your tokens between them -- I'm referring to two completely separate devices that have no knowledge of each other.

Consider the typical two-factor auth setup flow for a consumer website:

  1. User logs in and navigates to the "set up 2FA" page.
  2. Site generates and displays a 2D barcode to the user.
  3. User takes a picture of the barcode with their 2FA app and it generates a token.
  4. User submits token to the site.
  5. Site validates/finalizes the setup and 2FA is enabled.

During step 3, if two different devices scanned the barcode, would they then begin to generate the same series of tokens? If so, would they have to scan the barcode at roughly the same time to start with the same initial values?

I'm curious if it is possible to either shoulder-surf the barcode from an unsuspecting user's screen or, for example, see a barcode in video footage (perhaps from a security camera or local news broadcast) and use that to clone a 2FA token without the user's knowledge.

smitelli
  • 2,035
  • 3
  • 15
  • 19
  • 2
    TOTP is based on a shared secret, the key. In the standard implementation, the key is all that's needed to generate the codes (the rest of the algorithm is based on time). If you are able to acquire the key, then you can calculate the current TOTP code. This is mentioned in the wiki article for TOTP: https://en.wikipedia.org/wiki/Time-based_One-time_Password_Algorithm – Jay Nov 16 '15 at 15:52
  • 1
    @Jay I guess I just wasn't sure if the client added its own random component when it generates its first token. The intention of step 4 was never clear to me: why the first token needed to be submitted. I figured it was either because a) it was part of the handshake, or b) the site just wants proof that the user actually set up a device and is not about to lock themselves out. – smitelli Nov 16 '15 at 16:13

1 Answers1

5

Basically, yes.

The algorithm used relies on the secret key (often provided in barcode form) and an accurate time. Based on the combination of these, it provides a short code which the server can compare against.

In fact, the server will usually accept the previous and next codes for a while too, since either the server, or the end user devices might well be slightly out - the tolerance for this is dependent on the security of the service, where high security implementations will assume the end user has a very accurate device, and lower security ones might allow the user to provide one of three tokens at any given time.

You can test this by setting up multiple devices with a single barcode - you don't even need to scan them at the same time. However, you do need their clocks to be in sync - if they are slightly out, one will show the "old" code for a while before updating.

Matthew
  • 27,233
  • 7
  • 87
  • 101
  • By defining two devices with the same serial number (i.e. same barcode) you are defeating the uniqueness of the devices. The algorithm is specifically designed to ensure each device is unique by providing a means for each device to have a distinct key. This is explicitly stated in RFC 4226. – JaimeCastells Nov 16 '15 at 16:27
  • @JaimeCastells Well, yes. That's kind of the point. If you have access to the original key, you will generate the same codes at any point in the future. The original key needs to be treated like a password, since it works as the same kind of validator. Therefore, if you shoulder surf the original key, or find it in an AD record, or anywhere else, you can generate the correct keys at any point. – Matthew Nov 16 '15 at 16:39
  • Quite right! Sorry, I misunderstood the point of the question on first reading. – JaimeCastells Nov 17 '15 at 01:47
  • Can confirm that this works, I use it to have a backup token with services that do not support backup tokens – jrtapsell Jan 23 '18 at 18:28