5

MFA recovery codes last forever until used. The TOTP codes expire as per the clock (e.g. 30 seconds).

Does the initial QR code to register a MFA device last forever until disabled by a MFA reset?

I'm imagining (expecting) that the key, like the recovery codes, expires in practice, if not by design.

I've tried to locate references either way and my google-fu is sending me in unhelpful directions.

4

This depends on the specific MFA system in play. While most app-based MFA uses either the RFC 6238 TOTP or RFC 4226 HOTP algorithms, the method for sharing the shared secret is not standardised.

Google otpauth: secret in the QR code

The most common scheme in use is the one originally implemented in Google Authenticator, which has become a de facto standard, of sorts. This involves a otpauth:// URI scheme that is commonly shared via a QR Code. These embed the secret directly into the URI as plaintext, and therefore both the URI and the QR Code encoding of it are usable forever - unless the shared secret is reset on the validator end. In this scheme, the QR code cannot "expire".

Steam/Proprietary pre-authenticated secret pull

However, there are systems that don't follow this approach. Some systems don't use QR codes at all; Steam Guard Mobile Authenticator is an example. It retrieves the key directly from the validator's servers, presumably initially authenticated via the user's single-factor login credentials.

Okta: 2-step secret pull

Okta Verify with Push does registration via QR code, but the QR code does not encode an otpauth:// URI and is not compatible with Google Authenticator. Instead, it encodes a proprietary token that the app then uses to retrieve the actual shared secret from the validator's servers (and register itself for push notifications/authentication in the process). This QR code is not reusable, and can also expire on the server end before it is registered.

Okta does provide the option for an alternative Google Authenticator-compatible registration, though this can be disabled by administrators.

Fortinet: 2-step secret pull

FortiToken Mobile also does registration via QR code, but again the QR code does not encode an otpauth:// URI and is not compatible with Google Authenticator. This is yet another proprietary token that the app uses to retrieve the actual shared secret from the validator's servers, much like Okta Verify with Push. The QR code that is shared with FortiToken has an expiry set at 72 hours and is not usable after that time, nor is it usable more than once

There is no officially supported way to register this secret in Google Authenticator or other token generators.

Same TOTP codes: different methods of sharing the seed

All of Steam Guard, Okta, and FortiToken use the RFC 6238 TOTP algorithm, with a secret that would work perfectly well in other applications implementing the same algorithm if you were able to extract/register it. Two of them use QR codes. But the shared secret is never encoded in the QR code, and the proprietary token that is in the QR code only lasts as long as the server is willing to exchange it for the actual shared secret.

5
  • 2
    As another aside, if you are able to bypass the application and OS protections (e.g. via a rooted phone), it typically is possible to retrieve the shared secret from those proprietary apps, encode it in a otpauth:// QR code, and then register it in as many Google/Microsoft/etc. authenticators as you like :)
    – Bob
    Aug 5 at 8:22
  • OKTA and Fortinet!! I knew there was a method, and it was really bugging me that I could find no reference and I forgot where I knew about an expiring setup code. I used to work with both those vendor's auth systems. I knew some companies wrapped their secrets in other processing layers.
    – schroeder
    Aug 5 at 9:09
  • Can you add any references to these techniques?
    – schroeder
    Aug 5 at 9:13
  • @schroeder Unfortunately, I never was able to find any documentation of Okta's proprietary method - that one is purely from personal experience. Someone else has noted that the push QR code is not compatible with Google, but their admins did leave the third-party option enabled. As for FortiToken, there is one convenient blog post describing the extraction (and decryption/deobfuscation) of the secret. No comment on why I know that one :)
    – Bob
    Aug 5 at 9:28
  • OATH-LDAP enrollment also uses a temporary enrollment password split in two parts. Aug 7 at 11:39
5

The bar code can be put through any reader -- there's nothing special or encrypted about it. (I've had to build this out before.)

For example go here and generate a QR:

https://stefansundin.github.io/2fa-qr/

For example, for a given Secret and Label, the QR code expands out as

otpauth://totp/<Label>?secret=<Secret>

There are some other possible attributes here (like how many digits and how quickly they expire) but Google Authenticator will ignore everything except the Label (which is just the readable part) and the Secret (which is the real important thing here -- this is the cryptological seed that is the basis for the TOTP algorithm.)

The secret is literally just randomness -- it's usually 16 characters in base32, for 128 bits of entropy. But there's nothing special about this otherwise; it is ONLY the secret.

As you can see -- the QR has almost nothing in it. A name and a secret. It will last forever, so if you are saving that QR (or the underlying otpauth:// URI) you should treat it as sensitively as your passwords.

Documentation on this format (Google's is the de facto standard, and you'll find this particular format works with most apps. Some vendors include extra data in here for their own purposes, but that would restrict usage to their own OTP app and not the larger set of them that exist.)

https://github.com/google/google-authenticator/wiki/Key-Uri-Format

On the algorithm:

https://datatracker.ietf.org/doc/html/rfc6238

7
  • So, the general case is that it's the bare key without any other processing? Other sites don't add a layer where the stored key is derived from the displayed key?
    – schroeder
    Aug 4 at 21:22
  • 1
    It can't be different -- the way the algorithm works (since it's offline computation) is that both sides must know the actual secret. The client app (on your phone or whatever) and the server do the same calculation based on the same seed and current time (and number of digits etc.) and then those 2 results (one which the server computes, one which the client computes and you type in) must match. There's no real way to add a layer -- the fundamentals of the algorithm require both sides knowing this shared secret.
    – Joe
    Aug 4 at 21:49
  • Remember: there is no communications during 2FA using this method. You have 2 different systems computing what should be the same value using the same timestamp and same secret. The app HAS to know the actual key, because there's no interaction with the server, ever.
    – Joe
    Aug 4 at 21:51
  • It can be different. Take a look at the now-accepted answer. I used to work with Okta and Fortinet auth systems and knew that some systems expired, but could not remember how/why/who.
    – schroeder
    Aug 5 at 9:13
  • 1
    Yes, you are correct for that type. But it is not the sole type. So my very first comment applies. Other sites add other layers to the RFC standard. And their apps are designed to accommodate. So, you are not wrong, but you are also not complete.
    – schroeder
    Aug 6 at 13:11
1

There are two different things: the key and the token.

The key is unique to your account, don't expire by themselves, and can be copied over and over. As soon as you activate the key, it will be saved on your profile and kept there forever.

If you don't activate the key and come back later, probably it will be changed because the server is just generating another random number as the key.

After the key is activated, you can generate TOTP tokens, and they expire. Typically they are good for 30 seconds before expiration, and server-side implementations let the server accept tokens outside validity but within some range. For example, Google Auth PAM module let the server accept tokens with plus or minus a minute, to account for clock drift.

1
  • yeah, yeah, I get the token part - can you delve more into the key and what protections, if any, are in the design or applied in practice?
    – schroeder
    Aug 4 at 21:24
0

As Mentioned by Joe, From personal experience and research, the TOTP codes or the codes that you would get sent to you via a text message or generated by an authenticator such as Google authenticator or Microsoft authenticator are generated using a secret. That secret does not expire unless of course your multi-factor login was forced to expire by someone on the admin side of things. Since that secret does not expire, nor will the QR code attached to that secret since that QR code is essentially the secret. Now if your secret ever changed such as if you disabled and re-enabled MFA on an account, then your previous QR code will no longer work since the secret attached to that QR code is no longer the secret that is attached to your account.

2
  • "Since that secret does not expire, nor will the QR code attached" -- that's a conclusion but without some reference or something concrete to back it up. Can you support that conclusion?
    – schroeder
    Aug 4 at 21:20
  • That´s how I do it when I design 2FA systems. I don't remember where I got this design pattern, but it's a good one.
    – ThoriumBR
    Aug 4 at 21:35

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.