Last year Google Authenticator started syncing secrets to the cloud[0] which means that those secrets can now be accessed in new ways outside of the user's control[1], which resulted in a huge breach at a startup called Retool[2].
From then on I started moving my company's team and contractors (as well as family and friends) off of Google Auth and onto Aegis.
The app is clean, easy to use, open source, has all the options we could dream off.
(and its privacy policy isn't tens-of-pages-long like some other apps, where privacy seemed to be part of the marketing strategy but not the product itself)
> I started moving my company's team and contractors (as well as family and friends) ... onto Aegis
An important question on this, if you don't mind:
If the phone, where Aegis was installed, is dead/lost/stolen, which options are available to make sure that access to the accounts linked to that phone wouldn't be lost either?
Every service I've used with TOTP codes (12 at current count) has given me some sort of randomised backup token at the same time to use if I lose my 2FA app. I store those somewhere separate. I'm not going to argue that this is user-friendly but AFAIK there's no reason you're obliged to use cloud backups today.
This is actually a pattern I really don't like: Why do I mostly get these thrown at me for TOTP, but not other 2FA methods? What am I supposed to do with these "backup codes"? Store them all in my password manager?
At that point, I might as well store the TOTP seed there and rely on its multifactor authentication – which is probably fair for many use cases, but suffers from the problem outlined by GP.
I think sites should treat TOTPs effectively equivalent to Passkeys, i.e. as maybe synced, maybe backed up, but maybe neither – and then the user needs an alternative login method, just like for all 2FA methods.
Personally, I use Bitwarden for passwords and store my 2FA seeds in a Keepass database on my PC and backed up to my cloud. It isn't perfect by any means but at least if my Bitwarden gets compromised, my 2FA tokens are safe and vice versa. If I lose control of both, welp, it's gonna be a bad time I guess.
Choosing 2FA segregates users into two buckets. Most people are satisfied with the risk of allowing password reset emails and social engineering attacks. They don't pick 2FA.
The rest are generally more sophisticated users, and are willing to risk loss of the entire account if they lose their credentials. That's the price for an overall increase in account security. From this perspective, it makes sense to provide backup codes as another tool in the DIY account-management toolbox.
These buckets oversimplify the situation, but they help explain why backup codes are offered as last-ditch authentication for 2FA.
I write the backup codes in a small paper notebook, kept in a drawer at home. I've had to use it maybe once in the past decade. It's very unlikely that I'll lose both my phone and the notebook at the same time. It's extremely unlikely that anyone who breaks into my house and finds this notebook, can do anything with it.
You can copy an encrypted backup file to a usb drive and then either copy that to a few other secure places or just put it in a safe depending on how much redundancy you need. I use Aegis these days as a backup MFA option for a yubikey. You can password protect access to open Aegis with its own unique password which I like (no cloud dependency or access), but it's kind of inconvenient if you have a decently sized password so I prefer it as the backup option if the yubikey goes missing.
You can optionally backup your encrypted data using Android's built-in backup utility tied to your Google account. It can, then, automatically restore codes when you sign in on a new device.
Does that back up TOTP seeds in Google Authenticator? I thought apps had to opt in to this type of backup and would assume that Authenticator doesn't, but Google has changed the Android backup mechanism so many times, I lost track.
It backs up TOTP seeds. You need to enable this manually. As a part of Android Device backup, Google does backup certain things automatically[1] but non-Google apps require explicit opt-in.
Interesting, thank you! I would have expected Google Authenticator to somehow tangle the encryption keys used to the device it’s running on, but apparently it doesn’t if this works.
Point of order: Retool got hit by an SMS phishing attack, and while they made a big deal out of Google syncing TOTP seeds, the real moral of their story is to stop using TOTP altogether; it's not phishing-resistant. Rather than cutting a whole team from one TOTP app to another, it would probably be a better idea to shift the whole team to an IdP that forces FIDO2. TOTP is obsolete.
It was not in my case. I found out about this feature when I saw the green cloud icon and pressed it to find out what it meant. At that time I was made aware the my data was saved in my Google account.
It's likely your company's administrator forced this default behavior. Cloud sync was an opt-in on my account too, fwiw. It would have been a huge story had it been opt-out.
TLDR: From what I can tell, the "consent" to cloud backup from Google Authenticator was misleading at best and blocked access to the tool until it was given. IMHO this is another example of Google forcing decisions on customers in order to extract even more data. Thumbs down!
It looks like Google didn't make clear what was happening... There are almost no settings in Authenticator and there is no place to turn "cloud backup" on or off. I found this article that described the feature when it rolled out.
If the screenshot is accurate, they blocked access to the tool until "consent" was given to backup codes to Google. The text itself is clear in retrospect but, in my opinion, implies that there will be a choice to backup to Google and that choice was never presented.
"Google Authenticator is Upgrading... You can now sign into your Google Account and backup your Google Authenticator codes to the cloud."
A button is presented labeled "Get Started" and, if you click it, Authenticator will backup all of your codes to the cloud.
I don't remember being presented with this screen but I don't remember a lot of things. I suspect I needed to get a code and simply clicked the button to get to the list of codes. If I read it, I likely thought there was a new setting and I could manage this "backing up" from there. Clearly this was not the case and I "consented" to let Google have all of by 2FA codes.
It's opt-in, yes, but via a dark pattern of "hey, cool new thing, say yes quickly?" as far as I remember it.
I remember getting tripped up by this, because I also have work credentials in there that by policy I'm not supposed to store in a synchronizing TOTP client, and Google Authenticator didn't even allow reviewing the TOTP seeds for the longest time, so this seemed like quite the departure from their previous security stance.
That sounded scary, but after reading into the Retool breach (thanks for pointing it out), it doesn't sound like Google Authenticator is completely to blame.
Retool points out the "attacker was able to navigate through multiple layers of security" [0], i.e.:
1. "through a SMS-based phishing attack" on "Several employees"
2. "one employee logged into the [SMS phishing] link", "logging into the fake portal"
3. "attacker called the [phished] employee" "and deepfaked our [IT team] employee’s actual voice"
4. "the [phished] employee grew more and more suspicious, but unfortunately did provide the attacker one ... (MFA) code" (over the call)
5. "The additional OTP token shared over the call was critical, because it allowed the attacker to add their own personal device to the employee’s Okta account, which allowed them to produce their own Okta MFA from that point forward."
6. "This enabled them to have an active GSuite session on that device." With "Google Authenticator synchronization feature that syncs MFA codes to the cloud", "if your Google account is compromised, so now are your MFA codes".
By #5, I'm thinking GA sync is about as blameworthy as Okta for allowing a device to be added with just a single additional OTP token shared over a phone call?
Here's a different perspective (tptacek) [1]:
>> We use OTPs extensively at Retool: it’s how we authenticate into [Google, Okta, internal VPN and Retool]
> They should stop using OTPs. OTPs are obsolete. For the past decade, the industry has been migrating from OTPs to phishing-proof authenticators: U2F, then WebAuthn, and now Passkeys†. The entire motivation for these new 2FA schemes is that OTPs are susceptible to phishing, and it is practically impossible to prevent phishing attacks with real user populations
> TOTP is dead. SMS is whatever "past dead" is. Whatever your system of record is for authentication (Okta, Google, what have you), it needs to require phishing-resistant authentication.
> My only concern is the present tense in this post about OTPs, and the diagnosis of the problem this post reached. The problem here isn't software custody of secrets. It's authenticators that only authenticate one way, from the user to the service.
I only started reading into the Retool case because there was the claim above that sounded serious and scary:
> Google Authenticator started syncing secrets to the cloud[0] which means that those secrets can now be accessed in new ways outside of the user's control[1], which resulted in a huge breach at a startup called Retool[2].
This is the fear I went back to Authy from Raivo (iirc they didn’t sync back then; besides I have never trusted iCloud sync) and Tofu. I lost access to two accounts that I would have wanted to avoid.
By the way, a few days back Twitter simply decided to stop accepting my 2FA keys. Luckily I was logged-in in another browser as well where I could disable 2FA. And no it didn’t accept backup code either.
So that’s another risk with 2FAs. What I am trying to say is — 2FA synced or not synced are problematic either way.
I am also wary of passkeys! What happens if my Apple (for example) account is disabled or I am locked out of it?
From then on I started moving my company's team and contractors (as well as family and friends) off of Google Auth and onto Aegis. The app is clean, easy to use, open source, has all the options we could dream off. (and its privacy policy isn't tens-of-pages-long like some other apps, where privacy seemed to be part of the marketing strategy but not the product itself)
I've been a very happy user.
[0]: https://news.ycombinator.com/item?id=35690398
[1]: https://news.ycombinator.com/item?id=35708869
[2]: https://news.ycombinator.com/item?id=37500895