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

Also - Google Authenticator now supports Google Account synchronization - from 2 days ago (464p,325c) :

https://news.ycombinator.com/item?id=35690398

I wonder how long until "Mastadon" becomes an accepted spelling, just like "imposter" seems to have replaced "impostor" over the last few years.

English schwas are killer.

I wouldn't mind getting my name back.

It's been a misspelling for a while it seems https://books.google.com/ngrams/graph?content=impostor%2Cimp...

Well that was quick

It would be nice if a company did the right thing by themselves, not only when the angry mob shows up.

I agree though, it was quick.

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?

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)

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.

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.

I thought it exists already. Apparently...not.

yes my thoughts exactly. I guess its best to assume the worst when profit motives are factored in.

Looks like you did not read the linked post.

will... add?!?

I don't get why anyone would use Google Authenticator over Authy which had device sync, backup and E2E encryption for years.

Microsoft Authenticator has backup options but doesn't indicate if there is encryption which is concerning.

https://support.microsoft.com/en-us/account-billing/back-up-...

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.

Because they use the Google ecosystem and don't want to deal with yet one more account with yet one more company. Easier to keep things in one place.

How is authy end to end encrypted?

My understanding is they encrypt your database with a password before syncing to the cloud. They don't sync the password and there's no recovery.

Doesn't Authy require a phone number? I don't know why you'd use Authy over something open source.

Yep they do, and I don't get it either. I deleted Authy a long time ago and switched to Aegis. No regrets.

I need to do this. I’m highly suss of Authy holding my phone number given it’s owned by Twilio. It just doesn’t feel right.

Google Authenticator is still virtually useless because Google routinely locks people out of their accounts with absolutely no recourse.

People shouldn't use Authy either due to the fact that they require a phone number.

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

Another happy Aegis user here adding my support for using it over alternatives.

So they didn't have sync for years, presumably because they felt like it was insecure - and when they finally add it, it's not E2E encrypted

It took them 12 years to add sync, I wonder how long E2EE will take

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.

And maybe those identities will be magically synced to and from central servers, which would not be so 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.

Security is a nightmare when you trust systems that you shouldn't trust. That's for sure.

Going from mobile phone numbers to smartphones is not an improvement. It's just going more expensive and more monopolized.

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).

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.

Sounds like damage control wrt the last post.

Sorry nope.. privacy, encryption, security is not their thing.

Even if they’d have e2ee, it’s just a patch to a bad culture

Key quote:

> 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.

Underneath all the layers of security and encryption and footguns is still almost always a password...

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.

Agreed.

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.

> they lose the master password

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.

I did that for my mother.

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.

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?

Depends of what problem you are trying to prevent.

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.

Yeah my concern is theft or hacking more so than evil maid. I’ll keep it in mind if that changes.

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.

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 ...

sneak's law: users can not and will not securely manage ( = {generate, backup, authenticate} ) key material.

Any system that expects users to preserve keys is going to fail.

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 much contempt..

> 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.

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.

> If you use Gmail, all your password resets will go to your Gmail which also isn't E2EE

But it sort of is since it's sent over https, no?

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.

No. End-to-end encryption means: only the sender and recipient can read the content, not any intermediate party or service provider.

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.

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.

> 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! To your point, this is a great feature but allows more oblivious users to shoot themselves in the foot, so it's not the default.

Here's Google's docs on how to setup a passphrase/E2EE on Chrome sync: https://support.google.com/chrome/answer/165139?hl=en&co=GEN...

> 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.

> ...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!

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).

Good point.

> Calling this 'end-to-end encryption' really bothers me, as we already get that from HTTPS.

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.