It's a tradeoff. They could let (or require) a password be entered to encrypt/decrypt it on each device, but then people would be ticked off when they forget their password and can't recover their 2FA stuff.<p>They should have handled it the same way they do Sync in chrome, and I expect they will eventually. But, as always, unless a service advertises that it's full E2EE <i>and</i> you can verify that, assume it's not.<p>One part of this that's funny to me:<p>>>>Also, 2FA QR codes typically contain other information such as account name and the name of the service (e.g. Twitter, Amazon, etc). Since Google can see all this data, it knows which online services you use, and could potentially use this information for personalized ads.<p>I guarantee you, Google knows which online services you use in about 800 other ways, it doesn't need to scrape it from your 2FA accounts.
> if someone obtains access to your Google Account, all of your 2FA secrets would be compromised.<p>This overlooks that fact Google itself also has access to your 2FA secrets, which could be even worse considering Google could be requested to peer not just into the user's <i>google</i> account, but into accounts they have with other companies/organisations too.
It's a dual facing problem. Not only do users have no defence against google snooping, but google has no defence against requests to snoop: Apple seems to drive harder to "we'd help if we could, but we can't: to us its just blobs"
After my phone was stolen last month, I switched to <a href="https://2fas.com" rel="nofollow">https://2fas.com</a> and couldn't be any happier.<p>It's free, open source and has tons of great features.
Is there anyone who operates an authentication service which:<p>- Has a contractual obligation to keep your data secure.<p>- Accepts financial responsibility for data compromise.<p>- Carries insurance and bonding to back that responsibility.<p>- Does not require binding arbitration or forbid class actions.<p>- Has their employees bonded in the way bank employees are bonded.<p>Well?
But all that juicy data they could steal would just be going to waste when they did this.<p>I was really annoyed when iDrive, the backup service, pulled this stunt. Originally, they didn't have access to your encryption key. Then they put a dark pattern on their site to encourage users to give them the encryption key, to support the "the Cloud interface". Then you needed to give them the encryption key for some support functions.
I can recommend Aegis Authenticator - <a href="https://getaegis.app/" rel="nofollow">https://getaegis.app/</a><p>It has an option for encrypted, automated backups to Google or Nextcloud.
> <i>likely</i> even while they’re stored on their servers.<p>I'm all for castigating Google for not encrypting the TOTP seed which is (apparently) transmitted in the clear, but there's no actual proof (one way or the other) that the secrets are/are not being stored encrypted. Thus claiming "even while stored" claim is a bit much.
Imagine your google account getting deleted cuz you got banned from Google and the suddenly you lose all your 2FA secrets cuz they are part of that account
Someone will, of course, claim Google would never do this, but this presumably would make it trivial for Google itself to log into all of your accounts. In many cases they are already syncing a copy of your passwords.
FreeOTP recently gained support for backups to local file storage or cloud providers. The backups are encrypted with a passphrase, so the cloud provider can't obtain your OTP keys.
What? Why would this not get the same end-to-end encryption as Android backups? They'd have to do extra work to make this less secure.<p>Edit: oh I guess because it supports syncing between Android and iOS? Still lame, they should at least have an option to use the normal Android backup system. Which should have been the default since the start.
Why don’t people use their own TOTP provider, like KeepassXC/Strongbox, storing the DB in an encrypted manner on a cloud of their choice.<p>Then use across multiple devices.<p>It took time for this to sync in, so maybe that’s why so many others do not see that there is really no need to have a third party involved in this pattern?
I think Mysk just described "sync the secrets to your Google account." E2E would rather imply that there's a second E, but that's not the use case here.<p>If you already have a second E, just use the QR export/import feature.
tl;dr if a hacker gets access to your Google account it'll be like you didn't have 2FA at all<p>to be fair, storing your 2FA seeds in 1Password is about the same, except 1Password supposedly can't see your secrets. but if a hacker gets access to your unlocked 1Password data it's the same<p>tl;dr2 use offline TOTP or similar for real 2FA
Now I wonder if this just a bad netsec beginners mistake (dev, tester, pm all being stupid),
or if it's unencrypted on purpose? Both options are not thrilling.
Can the title get changed?<p>- E2E in this case is nebulous, this isn't a chat or email client, it isn't client <-> client with Google acting as an intermediary. It is between your Google account/Google's Server and Google's software.<p>- It isn't clear if during transportation it is encrypted (e.g. HTTPS?); since seemingly this post isn't about that (or if it is the evidence or technical information is lacking). The term "E2EE" typically is referring to encryption from client <-> client through a blind intermediary, but again that doesn't describe the relationship here.<p>The actual complaint SEEMS to be:<p>> Google Authenticator backup isn't encrypted at rest on Google's Servers<p>My big complaint is that this is a misuse of the term "E2E" (E2EE). It simply doesn't apply in this situation. That doesn't mean it isn't discussion worthy (e.g. not using HTTPS is a major red flag, and not encrypting at rest on Google's Servers is discussable).<p>In general the linked post doesn't do a good job describing what they found and how they found it.