[HN Gopher] Google will add E2E encryption to Authenticator backups
___________________________________________________________________
Google will add E2E encryption to Authenticator backups
Author : gnabgib
Score : 153 points
Date : 2023-04-26 21:46 UTC (1 days ago)
(HTM) web link (www.bleepingcomputer.com)
(TXT) w3m dump (www.bleepingcomputer.com)
| ballresin wrote:
| will... add?!?
| jacooper wrote:
| Well that was quick
| great_psy wrote:
| It would be nice if a company did the right thing by
| themselves, not only when the angry mob shows up.
| pgeorgi wrote:
| 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)
| coding123 wrote:
| 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?
| miohtama wrote:
| 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.
| miohtama wrote:
| 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.
| amf12 wrote:
| > 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.
| helpfulclippy wrote:
| 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.
| wslh wrote:
| 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.
| danuker wrote:
| And maybe those identities will be magically synced to and from
| central servers, which would not be so great.
| judge2020 wrote:
| 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.
| wslh wrote:
| Security is a nightmare when you trust systems that you
| shouldn't trust. That's for sure.
| xdennis wrote:
| 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).
| BiteCode_dev wrote:
| 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.
| heipei wrote:
| I don't get why anyone would use Google Authenticator over Authy
| which had device sync, backup and E2E encryption for years.
| crazygringo wrote:
| 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.
| toastal wrote:
| Doesn't Authy require a phone number? I don't know why you'd
| use Authy over something open source.
| leotravis10 wrote:
| Yep they do, and I don't get it either. I deleted Authy a
| long time ago and switched to Aegis. No regrets.
| shortcake27 wrote:
| 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.
| mey wrote:
| 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-...
| skinkestek wrote:
| 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.
| leotravis10 wrote:
| 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
| jjnoakes wrote:
| Another happy Aegis user here adding my support for using it
| over alternatives.
| jacooper wrote:
| How is authy end to end encrypted?
| nicpottier wrote:
| 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.
| gnabgib wrote:
| 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
| ortusdux wrote:
| Also - Google Authenticator now supports Google Account
| synchronization - from 2 days ago (464p,325c) :
|
| https://news.ycombinator.com/item?id=35690398
| jordigh wrote:
| 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.
| masto wrote:
| I wouldn't mind getting my name back.
| judge2020 wrote:
| It's been a misspelling for a while it seems https://books.go
| ogle.com/ngrams/graph?content=impostor%2Cimp...
| jbverschoor wrote:
| 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
| ezfe wrote:
| 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
| crazygringo wrote:
| 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.
| hanniabu wrote:
| > 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?
| Sohcahtoa82 wrote:
| 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.
| brazzy wrote:
| 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.
| sneak wrote:
| 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.
| cameronh90 wrote:
| 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.
| dmatech wrote:
| 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.
| thorncorona wrote:
| 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.
| dmatech wrote:
| 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.
| candiddevmike wrote:
| Underneath all the layers of security and encryption and
| footguns is still almost always a password...
| taeric wrote:
| 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.
| Someone1234 wrote:
| 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.
| wtf_srsly wrote:
| 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.
| ehhthing wrote:
| 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.
| varenc wrote:
| 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.
| [deleted]
| varenc wrote:
| > "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.
|
| 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=...
| brundolf wrote:
| 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
| kortex wrote:
| 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.
| BiteCode_dev wrote:
| 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.
| moviuro wrote:
| > 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.
| BiteCode_dev wrote:
| 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.
| ploxiln wrote:
| 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 ...
| ls612 wrote:
| 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?
| BiteCode_dev wrote:
| 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.
| ls612 wrote:
| Yeah my concern is theft or hacking more so than evil
| maid. I'll keep it in mind if that changes.
| mynameisvlad wrote:
| 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.
| modeless wrote:
| > 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.
| ignoramous wrote:
| > _...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!
| worldsavior wrote:
| I thought it exists already. Apparently...not.
| DesiLurker wrote:
| yes my thoughts exactly. I guess its best to assume the worst
| when profit motives are factored in.
| amf12 wrote:
| Looks like you did not read the linked post.
| 0xbadcafebee wrote:
| It took them 12 years to add sync, I wonder how long E2EE will
| take
| 1attice wrote:
| 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.)
___________________________________________________________________
(page generated 2023-04-27 23:01 UTC)