[rabboRubble]

pro-tip for next, back up the otp set up keys or capture the qr code during initial sign up.

i've been able to do this because i replicated otp set up in a second source (1password).

in 1password, edit the record then inspect the otp field string. it will look like this:

otpauth://totp/Discord:[e-mail]?secret=blahblahblah&issuer=Discord

save the "blahblahblah" and you can manually recreate a token at any time.

[dcow]

Unless you truly want to uphold the property "the something I have is not the something that stores my passwords" (you likely don't), your two factor codes should be in your password manager. Period. A good password manager has a strong user/device PKI backed by an offline key and will only be accessible on devices you've bootstrapped, so it's isomorphic to "something I have" at least and usually exactly equal to "somethings I have". And if you are a security nut trying to uphold that property and telling people it's bad to put your TOTP urls in your password manager... you better not have an authenticator app installed on the same device as your password manager or you've thrown that property out the window. Not saying it's never appropriate to have a true second factor. Just that it's not appropriate for 99% of consumer use cases and the security setup and structure afforded by password managers is more than sufficient to have good account hygiene. It would be a better world if everyone used a password manager and stored their totp codes in it than everyone has a hodgepodge of authentication apps that aren't reliable and break and cause services to implement manual verification backdoor loopholes into their auth anyway etc. etc. TOTP 2FA defends against weak passwords. A password manager enables strong passwords largely making TOTP irrelevant. Unfortunately not everyone uses a password manager and thus services are compelled to add TOTP 2FA because what other choice do they have?

[rabboRubble]

yeah, the only reason that i didn't get burned like the person above my original quote is that i got lucky. i had figured out that i could have two tokens running at the same time (one token for service A in Google Authenticator, second token for service A in 1Password). But I realized when I lost all Google Authenticator tokens one time, that I was this close || to a disaster. I had only recently also set up 1pw.

The most ideal set up would be to have a universally Yubikey or something equivalent. Preferrably with a backup pre-configured second Yukibey possible in a disaster recovery bugout kit. Then have all the initial QR codes, otp secret manual otp key strings like i demonstrated above your post, account recovery keys, backup break-in codes, or whatever other flavor of two-factor recovery a service uses, all this notated in a secured password manager. The real problem i see with two factor is that the offered recovery method is so variable from service to service. it makes knowing which information you need to have on hand when you've gotten locked out is problematic.

the other thing i do is that for core cloud service providers, i print out the password manager details for the accounts. this is apple, cloud backup service, google, microsoft and a couple of hardware device passwords. it's a risk to have this printed, but the print out is in a fireproof safe with a trusted party.

i basically assume my disaster recovery plan is that i have my wallet and the clothes on my back and nothing else. everything else gone including my computers and phones and i have to get back all services and data without having any devices.

the higher the level of security, the higher level of disaster preparedness the end user needs to practice.

I've emailed my elderly parents to make sure they understand that this mandatory 2fa roll out is happening, and I've explained how they could fuck up their accounts by not notating the recovery method. offered to review their details to make sure it passes a sniff test.