Google will add E2E encryption to Authenticator backups
bleepingcomputer.com
bleepingcomputer.com
> Google Group Product Manager Christiaan Brand told BleepingComputer that due to the possibility of end-to-end encryption causing users to get locked out of their own data, they are rolling out this feature carefully in their products.
I know everyone's pro-E2EE here but this rationale should be taken seriously. I absolutely believe E2EE is an important option to have, but it also makes sense for it not to be the default.
If you keep all your passwords synced in Chrome, for instance, none of them are behind E2EE either. If you use Gmail, all your password resets will go to your Gmail which also isn't E2EE. If you use Google Voice, SMS login codes will go to that, also not E2EE. It's not like syncing Authenticator data is less secure than anything else, and Google accounts are already awfully secure generally.
For most people, adding a new password/key just for Authenticator is just one more thing to forget/lose, especially since it's something they'll probably only touch every couple years. I think it's good to add E2EE as an option, but only for the minority of users for whom the necessity of extra security outweighs the risk of losing access entirely.
I introduced several times password managers to my friends and family, and more often than not, it was a disaster.
Because eventually, either they set a very simple master password they reused elsewhere, defeating the entire purpose of the whole exercise, or they lost the master password.
The latter meant they lost a lot of accesses (unless they have backup discipline, which of course they can't have by nature) because there is no recovery.
So the alternative was for me to hold the backup passwords or recovery passphrase/seed. So much for making them independent.
Bottom lines: security sucks and ergonomics sucks because most users are not tech saavy enough to handle complicated cases.
Making E2EE even an option is nice, and the best you can do for now.
The threat model for every lambda user having a password manager does not cover breaking and entering[0]: they should write down their master password and keep it at home in their bedroom drawer.
Use biometrics where possible (e.g. bitwarden on Android has that option)
[0] maybe it does for you, working on some DoD-confidential docs, but your computer-illiterate aunt doesn't.
She lost it anyway. TWICE.
As for bio-metrics they are not possible on all devices, and some software will require you to enter the master password once in a while even if it's activated.
But even if it was not the case, if you loose your device, you need to setup the new one, and for that, you need the master password or have backups.
Back to square one.
If you are trying to prevent most attacks from the internet, this is perfectly fine.
If you are trying to prevent a close person to gain access to your whole system, this could be improved.
It's not ideal, but it's better than the alternative of them reusing extremely easy to guess passwords.
Correction: You can enable E2EE on your Chrome passwords by setting up a passphrase! This enables E2EE for most other sync data as well. To your point, this is a great feature, but it allows more oblivious users to shoot themselves in the foot, so it's not the default.
Here's Google's documentation on how to set up a passphrase/E2EE on Chrome sync: https://support.google.com/chrome/answer/165139?hl=en#zippy=...
I think Google shipped another underbaked product here. They have E2EE implemented for Chrome sync data already. They should have just used that rather than going with whatever system they decided. Adding Google Authenticator to the Chrome Password Manager is probably much more useful than having it as a standalone app.
Also I'm sure there's many use cases for Authenticator when you're not already in Chrome or even in a web browser. Stuff like entering a 2FA key when logging into your VPN. It'd be awkward in that situation to pull up Chrome and find some obscure menu just to get your VPN's 2FA code.
The closest we really have is biometrics but even those have complexities, particularly with deep-fake style tech getting really near perefect.
Any system that expects users to preserve keys is going to fail.
A friend of mine had a stroke unexpectedly in his 40s which ruined his language memory. Regaining access to much of his digital life was somewhere between difficult and impossible.
So all technology ends up being designed for careless and irresponsible people because it's generally profitable to do this. If you don't, someone else will.
> So all technology ends up being designed for careless and irresponsible people because it's generally profitable to do this
So all of technology ends up getting designed for life, which generally will throw obstacles in your way. And therefore people will build escape hatches.
The problem is, Google can and does hand over user data to law enforcement. By handling MFA secrets without e2ee, Google is not doing any one any favours. I mean, it isn't like Signal and WhatsApp (apps with more users than Google Authenticator) haven't figured out a good UI for it for years now!
But it sort of is since it's sent over https, no?
And Google is not the sender of your password reset emails, they are a service provider, and they have full unencrypted access to the content.
End-to-End Encryption means that nobody between you and the person you're communicating with can decrypt the data, not even the middle-man service facilitating the communication.
In the case of Gmail, the content itself is not encrypted. Google can read the e-mail. It's likely encrypted at rest, but Google has the key.
This is false. Android backups are end-to-end encrypted with the ability to recover after device loss. Google already solved this problem years ago. Now instead of letting Authenticator use that solution (which it should have been using since the start, and would be the simplest thing in the world to implement) they had to build a whole new custom thing that is worse. But hey, I bet someone got a promotion for shipping a new feature.
English schwas are killer.
The only improvement is that you don't have to link your account to government photo ID (which is mandatory in many countries to buy a SIM card).
But U2F/Fido identities are better in that the people who prefer to ensure their keys are in escrow with a corporate overlord can choose to do that, while security-conscious people can go a step further and use physical security keys or third-party solutions with different sync mechanisms.
Then we just have put all the things in the same basket for the convenience of mass spying, like we did with https, which any entity big enough can MITM by using their root certificates.
What this ought to be called is 'encrypted-at-rest' (EAR).
Words are important; there's an obvious downgrade attack where E2EE is implemented as EAR, but then later watered down to something like HTTPS (where the pipes are encrypted but that data is stored unencrypted.) You could do this without changing the language of the product offering, provided that the product is sold and marketed as 'end-to-end'.
Whereas if you created an EAR system and marketed as such, you'd be vulnerable to lawsuits if you pulled a bait-switch (which you might have done because the FBI is leaning on you.)
You very rarely get end-to-end encryption from HTTPS.
It's possible, if the TLS session is actually between the two ultimate end points (the two ends in end-to-end). But that's very rarely the case.
https://support.microsoft.com/en-us/account-billing/back-up-...
So I lost my 2-factors, luckily I had spares for most.
Google Authenticator is still virtually useless because Google routinely locks people out of their accounts with absolutely no recourse.
I and I'm sure many others should rely on open source alternatives. Here's two examples:
Aegis (Android): https://getaegis.app Tofu (iOS): https://tofuauth.com
- Keep things as they are
- Avoid TOTP data getting lost with lost passwords
- Avoid TOTP data getting distributed when the Google-side backup ends up becoming public
Maybe this might have been a suitable situation for a "beta" label, though: "We have this, it offers advantages, it has caveats, if you don't care about them, feel free to sign up, otherwise wait until we sorted it out."
(Disclosure: work at Google, but no insight into what Authenticator is doing)
It seems like most of the time when there's some kind of outrage (at least on HN) there's just silence for 20 - 40 days, then some kind of announcement that either doubles down or backs off. This whole outrage started what, Yesterday?
They are encrypted while transit and at rest, just not E2EE, which is understandable based on the link, but still should be an option like passoword manager in Chrome has.
Sorry nope.. privacy, encryption, security is not their thing.
Even if they’d have e2ee, it’s just a patch to a bad culture