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.
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:
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.
otpauth: secret in the QR codeThe 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".
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 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.
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.
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.
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.
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.
