> 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.
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.
I've given some family members small paper pads and encouraged them to write down important passwords, and keep them in their home office. This way they can at least have a chance with semi-reasonable unique passwords, vs falling back to using the same trivial password for everything, and still needing to reset it twice a year ...
For the few keys I need to remember (external drive bitlocker key, windows password, etc) I do reuse a few passwords but I used passwords that have never been used on the internet, so I should be preventing the password reuse risk from breaches. Is there something I’m missing in this strategy?
The way I've done it with close family is that I kept a copy of their master password in my own vault (or the shared family one) to remind them when they inevitably forgot.
It's not ideal, but it's better than the alternative of them reusing extremely easy to guess passwords.
> "If you keep all your passwords synced in Chrome, for instance, none of them are behind E2EE either."
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.
Aren't the Chrome passswords part of the (optionally) E2EE encrypted data?
It might not be the default but AFAIK they definitely _can_ be E2EE encrypted.
Yes, this is an option (that you definitely should turn on).
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.
I can see Google's rationale for keeping them seperate. It is supposed to be the 2nd factor after all, and if your 2FA secrets are stored and synced right along with your passwords that really makes it not much of a second factor. The same can be said for any cloud based 2FA secret syncing, but I believe for most users they still only have 1 phone with Authenticator and the 2FA secrets on them, and this cloud syncing is just about allowing someone that gets a new phone to restore their 2FA secrets. That's pretty different from actively syncing your passwords between all of your mobile and desktop devices like Chrome's sync does.
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.
We've invented better things, but they inherently have the problem of: What if I lose/break/etc my hardware token? What if it gets stolen? Plus of course the vendor lock-in potential.
The closest we really have is biometrics but even those have complexities, particularly with deep-fake style tech getting really near perefect.
I'd rephrase. Underneath it all is a secret. Classically, passwords were shared secrets with someone. Everything since has come down to a way to not require direct sharing.
Any of us are just a medical incident away from forgetting all of our passwords.
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.
That's because users don't have to suffer the permanent effects of their carelessness. There will always be someone they can scream at and blame for things going wrong. Because they're the customer, and the customer is entitled to satisfaction.
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.
It's not difficult to learn how all this stuff works and be careful not to lose hardware keys. But most people would rather think about other things and just call customer service if they get locked out. That's understandable, but I wish people would take more responsibility for their own security.
Authy does a neat thing where it prompts you to re-enter your password every couple weeks even though it doesn't need it, just as a practice to keep it fresh in your mind
Honestly everything should do this. If it's saved in a password manager, it ensures you still have access to it, and if it's memory, it serves as a kind of spaced repetition to keep those neural pathways strengthened.
> ...but only for the minority of users for whom the necessity of extra security outweighs the risk of losing access entirely.
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!
Merely being sent over HTTPS does not guarantee full E2EE.
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.
> It's not like syncing Authenticator data is less secure than anything else
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.
Related discussion yesterday: Authenticator cloud sync: Google can see the secrets, even while stored (378 points, 126 comments) which is from the Mastadon version of the twitter post quoted. https://news.ycombinator.com/item?id=35708869
I think the big picture is that security is winning: Apple also adding U2F, etc. All this implies that we will see more E2E and identities disconnected from our mobile phone numbers, which is great.
The option to "sign in with" a third-party provider is already extremely widespread and most people prefer it.
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.
Well, until we learn that there is a backdoor in their implementation, allowing any big actor to swoop in and either crack the crypto easily, have access to an unencrypted copy, or steal the passphrase.
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.
Calling this 'end-to-end encryption' really bothers me, as we already get that from HTTPS.
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.)
Does encrypted at rest necessarily preclude Google from retaining keys? It seems like the same schtick Apple had for all these years where they said iCloud data was fully encrypted (which was true) in the hopes everyone would conflate "encrypted" (you and them have the keys) and e2ee (where they don't handle the keys).
Also I burned myself by activating backups in the app and not realizing I had to activate it in system settings in iOS too (or something to that effect).
So I lost my 2-factors, luckily I had spares for most.
That quick response is indicative that E2EE might have been on the roadmap already. It's a bunch of trade-offs:
- 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?
How the f** they did not have them encrypted to begin with? Since when Google has become totally incompetent. They are quite sure that two-factor authenticator is use on security sensitive properties, including Google’s own services. This is like begging Google Drive hackers to get your two-factor seeds.
I am on the whole not that impressed with the quality of Google stuff. It's not like it was 20 years ago, when seeing the Google version of something was really exciting, like when Search, Gmail or Maps first came out. Now I look at Google about how I looked at Microsoft back then... a company whose products that I'm generally better off avoiding, and when I do use them, it's usually not because of the product quality itself.
> How the f* they did not have them encrypted to begin with?
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.
How the f** they did not have them to begin with? Since when Google has become totally incompetent. They are quite sure that two-factor authenticator is use on security sensitive properties, including Google’s own services. This is like begging Google Drive hackers to get your two-factor seeds.
> 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.