Add another perspective to this. Once I updated my phone, and google would not accept new google Authenticator codes after set up. Locked out of 15 years of email.
They specifically provide 10 one use codes for this type of situation that should be saved somewhere. Also, email should be backed up locally if it’s important, just like anything else.
I’m not sure what else people want from a secure email service you don’t have to pay for. Also, any work around the 2FA by a human simply means less security for everyone.
I had a fright last time I changed phones. After restoring my backup onto the new phone, I was about to wipe the old one; I did a final pass through my apps just in case... and saw that Google Authenticator configuration did not carry over to the new phone (which makes sens from a security perspective but is a PITA to manage). I had to re-enroll my device with all the services on which I use MFA.
After this episode I made damn sure I had recovery codes stored in a safe place.
When a family member had a phone stolen not long ago, the only major functionality on it that they couldn't quickly and securely disable was the Google stuff.
The procedures for doing so seemed to be unnecessarily complicated and difficult to find when starting, ironically, from a Google search on another device.
Worse, the security policies seemed to be fundamentally flawed, because they kept insisting on some form of authentication based on a trusted device when the purpose of the transaction was to notify them that the trusted device had been stolen.
There has been an unhealthy trend recently of assuming that everyone has a mobile phone and that communications to that phone/number are a good method of authentication, without adequate thought to what happens if the physical device and/or the associated phone number are compromised, or to whether protocols like SMS are really suitable for this sort of application. And some of the really important things, like banks and government services and email providers (which are in practice a gateway to everything else you do online) are often among the worst offenders. I don't know what to do about this, but certainly raising awareness of this kind of problem would be a good start.
> Worse, the security policies seemed to be fundamentally flawed, because they kept insisting on some form of authentication based on a trusted device when the purpose of the transaction was to notify them that the trusted device had been stolen.
Are you suggesting any random person without any authentication proof to be able to just sign people out of their devices ? That would be a broken security.
I'm suggesting that a security policy should actually be practical. There are any number of viable ways to handle this. Requiring someone to possess the device they are reporting stolen is not one of them.
You can also have more than one device set up for TOTP - phone, previous phone or tablet, desktop using WinAuth or similar. Authy and the password managers will also track those seed values, though it's best to store them separately from your actual password storage.
Another thing that will not migrate phone to phone is Signal conversations if you're inclined to keep those.
Yes, I lost my Signal conversation history as well and had to be re-added to all group conversations (another PITA).
How do you store seed values in password managers? More specifically: how do you export them from Coogle Authenticator? (I’ve not found that option). And how do you import them again?
ISTR at least one service (AWS or Google) asking for the first 2 codes after scanning the QR code, probably to sync. So I always assumed simply re-scanning the QR code wouldn’t be enough but maybe it is this simple.
The underlying technology behind (almost?) all of these is TOTP (https://en.wikipedia.org/wiki/Time-based_One-time_Password_a...) which pretty much just depends on both systems having clocks that are reasonably close to synced. The initial value is basically a random number generator seed, and given the seed and a number of iterations (based on the time differential from a set starting point) calculating a code is fairly simple.
There would be problems on fully-isolated systems experiencing clock drift, but on any modern Internet-connected system using NTP or on any cell phone with time synced to the network it shouldn't be a factor. The most likely problem scenario is probably a corporate network using only an internal time source that drifts.
Doing a single code as validation only makes sense to catch transcription errors since in case of problems someone could end up locked out of an account.
For the future, if you use yubikeys, yubico authenticator is a drop in replacement for google-authenticator and you can save your google-auth setup on multiple yubikeys. So, even if you lose one, you still have it on another. Then it is independent of the phone. Also the yubikeys themselves can be used as 2FA for google accounts. However, sadly, you can't set them up on firefox the last time I tried.
Happened to me too. The thing that triggered lockout was attempt to login from different country (I've changed my VPN provider). I didn't give Google my phone number so the only option left for recovery was tricky questions like "what city you've been logging in from" which I failed to answer.
