Neither was approved nor denied, just in limbo. But nice to see that both features have finally shipped. Sadly I have switched away to 1P, too much effort to move it all back.
Twice I've had to spend hours manually resetting/renabling my 2FA after a phone was damaged, and sans buying a new screen just to get a backup of the phone, there aren't many other options.
(Similarly, this was the time I learnt that the UK gov does not issue backup codes for their 2FA and you just have to spend 45 mins on hold to have them reset it for you.)
Unfortunately Google has the last laugh here, because since Android 12 even scrcpy can no longer bypass FLAG_SECURE. Currently you'd have to start messing about with root and using some sort of Xposed and/or Magisk (?) module to disable FLAG_SECURE in order to be able to mirror that kind of apps with scrcpy again.
For me, I'd usually be on the desktop when setting up 2FA anyway, so I'd just save the QR code from the desktop browser ("Save image as ..."). When I needed to set up a new phone, I'd open the saved image on the desktop and point my phone at the screen.
Screenshot -> Print is one backup method.
Screenshot -> Encrypt -> Save to secure location is another method.
Also, as of last week, there existed an issue with special characters when trying to import and the app would just freeze or not recognize the QR code pattern at all, so you better had backups of all your secret keys.
Both issues made me switch to Aegis and appreciate my past self backing up the secrets with KeePassXC.
They actively added code to prevent you taking screenshots, which is insane but true.
In any case, if you're trying to create a backup there are other avenues of capturing the QR code - offline digital camera is probably the most secure way of doing so.
Now it's tied to the Google Account which means it'll be tied to either their personal or work account and now we have to worry about personal account bans removing their 2FA or when they leave the company, our suspension process killing personal 2FA that were synced via the wrong account.
Not saying it's a particularly good way, but it's a way.
Do not use google-anything, for anything in production, ever. They make shiny products that depending on your point of view may be nice or just shiny. But their total solution is not a serious competitor to any of the major players. Any time anything depends on google, you risk it destroying a part of your business - yes, under a paid support contract.
I was doing a dc migration at a hospital once, and they used google authenticator. I'm waiting for the day some sysadmin who knows some dev who worked with some dev on an app that was banned from some phone that got resold, will cause all the storage, network, and sysadmins to lose remote login access to all their devices during a sev1 at 2am.
Apparently the authors of Signal consider backup to be less important than all the idiotic "story time" features and similar doodads.
It seems like a very, very bad thing to store both your passwords, and TOTP codes in the same tool...
I use Authy instead, which also backs up TOTPs.
I'm also having the same thoughts about Google Auth: my email (Gmail) is a big target for gaining access to the rest of my digital life, and putting 2FA in the same hands seems risky. I'd need to do more evaluation to consider leaving Authy.
If you are using a strong random password generated from 1PW you've already mitigated against that threat. TOTP isn't buying you much additional security. So for most folks it is just fine to store you TOTP seed in 1PW.
Unlike TOTP, passkeys _do_ buy you additional security in their phishing resistance. So you should always prefer passkeys/fido2 keys to TOTP if that is an option. Its still fine for most users to use 1PW as your passkey storage.
The only argument I can imagine is that if someone gets ahold of your phone it's either locked and they can unlock it or it's unlocked, in which case either your 1pw account and/or other TOTP apps are either locked or unlocked. In the worst case scenario where everything is unlocked, having a separate app is negligible.
Besides, AFAIK Google Authenticator doesn't require additional unlock steps, unlike authy or 1password.
You're better off worrying about how to avoid TOTP and securing 1password than about having TOTP codes stored alongside your passwords.
Why isn't TOTP buying much additional security?
It seems to me that apart from password reuse it's mitigating many other potential problems: keyloggers leaking passwords from your device, passwords leaking from the authenticating server, etc.
The only good solution is WebAuthn and related technologies (phone passkeys for disaster recovery), so that server side needs nothing more than a public key.
But lets say you are in fact a user that gets targeted by an adversary capable of deploying a key logger against you. Does TOTP protect you? No! If you are compromised to that point, the attacker is also in a position to just hijack your sessions.
There isn't a threat model out there that is trying to solve the problem of "my end user device has been compromised but I still want to be able to use it to access sensitive systems without those systems being compromised."
Storing both on 1Pass is not as secure, but the option is that once in a while you misstep and spend a week restoring TOTP setup (or lose entire accounts because your service provider has no functional customer support) then I'm amenable to stable but less secure options.
There are many non important accounts where I have 2FA, and both the password and the TOTP is in 1p. This should suffice for any brute force password attacks. However there are some accounts (like google) which one can consider more important for which I keep the TOTP on a separate app like Authy.
More recently I've been switching to yubikeys where possible.
I keep my 2fa backup codes in my Keepass safe. Where else will I keep them?
Yes. It defeats the purpose. But whenever you mention it, you will get lots of replies with plenty of hand-waving why this is still better and why it doesn't matter "much".
If you go to the effort of doing 2FA, do it right. Two Yubikeys, and a reasonably decent TOTP app (Authy qualifies as "reasonable") for those sites that do TOTP.
I’m glad there’s finally real support for backing up codes.
I'm in the process of moving to Aegis. It's FOSS, encrypts the file on the device, and supports the biometric lock. It can do a daily backup to a few sources, including the Google backup (I think) and personally I dump it to a folder that my Nexcloud will automatically upload to my personal server.
You'd need to involve the provider for changing token seeds.
At a client level, all you have is one seed.
If you save a seed, it can be used on any number of devices.
This basically means you can never factory reset your phone without someone else using their phone to help you, which means you're forced to share your entire account and all your codes with a third party who might keep them forever.
You also can't preemptively back it up in case your phone is stolen or lost.
But nope, Google thinks they know best and in 2023 they still actively block you from keeping your accounts safe. It's mad.
I just tested this using the copy function of my Brother printer/scanner, and my phone was able to successfully import from the printed export code.
I've only got 4 accounts in Google Authenticator (because I only have it because I wanted to help someone else once who was using it figure out something). The more accounts you have the denser the QR code will be, so it is possible that you might have to split the export into multiple passes with this method if you have a lot of accounts.