I remember pushing for this when i was at Google ~5 years ago. I wasn't on the team but I wrote 2 proposals, one to do QR code export and imports and another to sync codes using the google backup framework.
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.
Years ago I got FUCKED when I used Authenticator and bought a new phone. I just assumed everything would be backed up to iCloud, like everything else. I lost access to accounts which were almost impossible to retrieve. Millions of people have been screwed thus, turning people away from 2FA. I can't believe it has taken this long to enable sync.
Our onboarding docs specifically tell employees to NOT use Google Authenticator precisely because of this issue. I have no idea how Google let this fester for so long, literally if even one (1) person over there was using it and got a new phone, they should have known about the issue.
Yeah, same with my company. "DO NOT USE GOOGLE AUTHENTICATOR" is littered throughout our Intranet and onboarding docs in bold letters with recommendations for different options. And people still use it and lose their codes all the time.
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.
The app has supported bulk QR code export and import for years. This makes it easy to transfer to a new phone, and relatively easy to make physical backups.
Which only worked if you had both phones working at the same time... I'd bet a sizable portion of new phone enablements are due to losing the previous phone irrevocably.
When doing a factory reset because of whatever reason, this becomes an issue as well. You cannot take screenshots of the bulk export QR-Code on Android because of FLAG_SECURE, so you need to work around that and take a photo of the screen with a different device to import from later.
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.
I have long migrated to Aegis and it is pretty awesome. Backups. Copy & Paste. Encryption. Auto-upload to Nextcloud. Better Interface (with names!). etc.
You'd save the QR code at the time you first used it on the old phone, and not wait for when you needed to transfer it.
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.
That's an absurd expectation. First of all, many users don't even have or use a computer. Of course, I personally do have one, but I'm often nowhere near one when I set up MFA on a new account. So then I guess I screenshot the QR code to my phone? But if I saved the image to my phone it gets stored in my photos backup anyway. Why would Authenticator not just back its own contents up, to that exact same spot, rather than me doing some crazy runaround that for some reason involves images?
Nope, you can't screenshot the page, so you can't save the code and can't send it to another phone. This means you can never trade in a phone for a new one and if your phone is lost or stolen you're locked out of all your accounts forever.
They actively added code to prevent you taking screenshots, which is insane but true.
I'm on iOS and I'm able to screenshot the QR code with version 3.4.0 of the app. Maybe the screenshot lockdown is limited to Android?
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.
Interesting - but not good enough. For the threat model TOTP solves, it is not absurd to want Authy-like functionality where codes can be backed up, encrypted, to a cloud service OR like Authone (?) which allows you to export the data to a file.
This is not a 2FA problem. It's a google problem, and the google problem is not limited to 2FA.
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.
Incidentally, Signal works the same way on an Apple device. No backup. Lose your phone, and your entire chat history is GONE, together with all the media.
Apparently the authors of Signal consider backup to be less important than all the idiotic "story time" features and similar doodads.
I'm so much with you on this. I love Signal, but I'll never recommend it until it gets backup/restore. I have no clue why this is not prioritized over everything else.
Yep, I’ve been using Authy for years because of this. Before that, I would have a second phone with GAuthenticator on it and when I scanned the QR code to set up a new account, I would do it with both phones simultaneously to make sure I had a backup. It always struck me as absolutely ridiculous.
Authy used to share its SDK TOTP codes with attackers via account recovery, and no backup password was needed. SMS hijacking led to authenticator takeover on Authy SDK-using sites like Coinbase. Which is partly why Authenticator and co. were originally designed to prohibit secret backup.
If you damage your Android screen it is basically useless unless you have pre-emptively set up some kind of remote access process...
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.)
Exactly this. I bought my current phone after I dropped my previous one and cracked its screen. I was only able to recover access to critical services because I have previously set up some Tasker automation connected to my Pebble watch, which enabled me to navigate the phone "in the dark" enough to turn on AirDroid, allowing me to screen-mirror the phone to the PC. Of course, all the 2FA tools have this stupid idea of blacking the screen when it's being mirrored - but fortunately, I was able to turn on USB debugging this way, at which point I plugged the phone in and used scrcpy to show a fat middle finger to Google and plain recover everything from Authenticator.
Now imagine trying to explain this to anyone outside of the tech industry. I imagine only a small percentage of software engineers and IT folks in general would be able to accomplish what you did. How easy it is to accidentally fuck yourself over with app-based 2FA is one reason I've been hesitant to recommend it to my non tech savvy friends and family. While SMS 2FA is a lot less secure, it's at least pretty much idiot-proof.
Yet this scenario (currently authenticated phone is gone) just seems a baffling concept to the people making these apps. I need to be able to make an offline backup for the day when the phone is lost or destroyed.
> and used scrcpy to show a fat middle finger to Google
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.
The main point of TOTP is that users passwords are mostly weak and reused across sites. TOTP protects those users from password stuffing and similar attacks.
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.
> 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.
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.
Not exactly the question you asked but one reason FIDO/Ubikey provides more protection than TOTP is that it won't send codes to the wrong website. If you're being phished skillfully, and don't notice the URL is wrong, you're protected in that way. If you use TOTP you have to verify the URL manually.
One way passwords leak from servers is when they're being inappropriately logged (like at the POST-level), which is not going to happen for TOTP seeds.
True enough. However, unlike a password, you can’t take a hash of it and thus reduce the consequence of exposure. It’s just another shared secret, albeit one that doesn’t rely on the fallibility of human creation.
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.
Furthermore the risk exposure to using TOTO in 1pw is almost insignificant. You can configure your 1password account to require 2FA when setting up new devices, and unlike Google here the decryption requires manual knowledge not shared with the cloud.
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.
In practice, no. Key loggers are a minuscule threat to account security compared to weak passwords and password reuse.
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."
Token binding was the closest we had - still lets a compromised endpoint in the right position steal and use the tokens from that device, but it's at least not persistent.
Keyloggers may not threaten people who habitually use personal devices, but I can see them still looming large for those who rely on public computers, in libraries, schools, coworking spaces, etc. YMMV.
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.
As a former Google Auth user, who bungled my own phone migration a few years ago - yeah, defense in depth is better but at the time, I was furious there was no way to recover my Google Auth and I had to go to every single service and reset my 2FA.
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.
> It seems like a very, very bad thing to store both your passwords, and TOTP codes in the same tool
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.
Very true, however as others have pointed out it all comes down to levels of security.
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.
Eh, it's still better than not having it. Which is likely the bar for a lot of casual users. Mostly the goal is to prevent password reuse I think, which comes down to convenience. And unless 1pass gets hacked (which could happen! see: LastPass) it's relatively secure for that purpose.
Yeah, but only as a means of transferring them to another device. Sure, you could abort the flow before the existing codes were deleted, but it was far from ideal.
I’m glad there’s finally real support for backing up codes.
Hmm no, I use this from time to time, and it really is just a way to copy the codes to another device. It won't delete them from the original device. It notifies the device owner after a few minutes that the TOTP have been exported, and it keeps a log of exports.
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.
It doesn't delete them from the existing device. However, it exports them via qr code, which it prevents you from screenshotting, meaning you can never factory reset your phone or protect yourself from theft or loss. You can only transfer to another phone when you have both devices working at the same time.
Does the export invalidate the existing device after export ? it sounded like it's only for moving to a different device rather than having two at the same time.
I would've even been happy if they didn't block you from screenshotting the QR export code. This has caused me so much pain over the years but nope, they refuse to change it.
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.
You can go to a place that has self-service photocopiers and copy the QR code(s) from the export screen(s) to paper that way.
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.
That was worst thing about google Authenticator was migrating to another device and amount of support my IT team had to deal with people upgrading phones. I can’t believe how long it took for an export feature.
Yeah, I switched away from Google for this reason. Pretty wild to think of the implications of losing your phone and having no backup. Even switching phones required resettings all your codes. Authy is a mess, but at least had this functionality when they were still actively worked on.
All you need is the OTP secret. I have all of mine stored in my bitwarden. I can plug and play them in any supporting app to keep generating the 2fa codes.
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.