Google Authenticator cloud sync: Google can see the secrets, even while stored
defcon.social
defcon.social
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 and you can verify that, assume it's not.
One part of this that's funny to me:
>>>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.
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.
And actually, they serve you emails, so password is moot for most of the sites today.
It’s possible to have 2FA methods that are verify only (usually using public keys and signing), but TOTP is not one of them.
Not to mention Google can be hacked.
A lot of companies and institutions use GA for 2FA for their secure systems too. Google doesn't even need to willingly share, as soon as the possibility of extracting the data is there they paint a target on it. External attacks are now extremely low hanging fruit with that unencrypted traffic. And internal attacks like getting an employee with access to that unencrypted data to provide it (knowingly or unknowingly) are relatively low effort and don't require the overhead of any legal proceedings or complex exploits. And if this goes through official/legal channels, Google doesn't have one single shred of protection between that data and what authorities can (shockingly legally) ask for.
Having the data is a liability for Google. Transferring it insecurely is also a liability for the user.
TBF knowing which online service you bothered to activate 2FA on is an information a lot more interesting than which mailing list you forgot to unsubscribe for instance.
Now I don't think they'd use if for ads, I'd assume it would probably be more long term, like knowing which service to buy next, or where the trends are going.
In contrast, subpoena'ing data from the cloud is routine for police in countries all over the world.
For example, in the past I've worked with an AI company with presence in China, where the data of their Chinese clientele must be stored on a separate data centre operated by a local enterprise.
Despite the provider being ISO compliant and holds internationally recognised certs, is there realistically a chance that those data could be accessed without the permission or consent of the users?
Under this model, if Google gets a court order to root-break a specific phone (push malicious update), they will be forced to, and that's all the legal framework necessary, so end-to-end encryption doesn't protect you in this case either.
"secure as practically possible" depends a lot on what practically means, and that is just a function of cost vs threat level. If you believe that Google will access your private data, you should not be using a Google-developed application and OS in the first place.
Everyone also might have "google play protect" enabled on their phones which allow google to pack and ship all and every app at regular intervals (no mention anywhere if it include user data) to their servers for threat analysis.
www.reddit.com/r/degoogle
It’s typically not a disaster if you lose the 2fa keys and if it is, you should carefully save the recovery codes. But the keys get lost all the time so just about every service has a recovery procedure. So there is no need to store the secrets in such a way they can be recovered without the password.
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 google account, but into accounts they have with other companies/organisations too.
(Without cloud backup, & without the installation of a malicious version of 'Google Authenticator', how would they – especially, say, on iOS?)
(And if Google were denied access to the cleartext 2FA secrete this, way, then briefly compromising someone's Google account – say by hacking or abuse of legal process – wouldn't automatically compromise all other 2FA-key-protected accounts.)
The only real "threat" is your Google account itself being compromised by a third party able to phish their way into your account or bypass your 2fa mechanisms (e.g. by SMS sim swapping). As always, https://landing.google.com/advancedprotection/
The people here saying "privacy" are speaking of some doomsday scenario where Google itself leaks all of this data, which would be unprecedented and is unlikely with how many safeguards there are for employees to access any user data at all within Google.
Just because there is only one key doesn't disqualify the solution from e2ee status. If the middleman does not have the key, it's still end to end secure.
The whole reason you'd enable this feature is for when you lose your phone and need to provision a replacement. There's not really any way to do the whole key exchange dance if you don't have access to the original source. A password derived key is essential in this case.
From the linked article [1]:
> December 2018: Google+ Bug Exposes 52.5 Million Users’ Data Google+ faced its second big breach of 2018 when a November update created an API bug that exposed data from 52.5 million Google+ accounts. Google fixed the bug within six days, and moved up Google+’s burial date from August to April 2019.
> Google originally decided to terminate Google+ after another breach became public earlier in 2018
and an earlier Google+ bug that was reported in WSJ [2]
> Google Exposed User Data, Feared Repercussions of Disclosing to Public
> Google opted not to disclose to users its discovery of a bug that gave outside developers access to private data. It found no evidence of misuse.
[1]: https://firewalltimes.com/google-data-breach-timeline
[2]: https://www.wsj.com/articles/google-exposed-user-data-feared... (Oct, 2018)
Source?
I think the default behaviour is not E2EE.
Under which assumptions should Google be forced to "peer into accounts a user has with other services"?
This is not only not enforceable, it would be illegal.
Companies can not be enlisted to do such things governmental agencies are doing. How should a company decide what to look for? Google is not the police and can not be made an investigator just-for-fun. FBI's search engine?!
Also, you need the first factor. Do you expect Google would also send the "password reset"-request, reset the password, use your 2nd factor... Just to be nice to the authorities?
Wild theory if you ask me...
Fine for what?
Gag order? Does not help them.
Legality? That would count, if it was something I could order them to do, but again, what do you think would happen there?
"Dear Google, we know you have user TechBro8615@gmail.com, could you please:
- Go through all your data, and gather which Accounts for which services TechBro8615 has
- Go through all these accounts TechBro8615 has with every possible service and reset all his passwords with these accounts (without him noticing)
- And use the second factor TechBro8615 has to login
- Make a user data takeout for all the data TechBro8615 has with all these services
- Create an index of this data, because, well we ask you to, although we can't make you do that
- Tell us if TechBro8615 likes Cranberry juice???
Legality does matter, if you request something from third parties. Why on earth should Google ever cooperate beyond step 1? Would you do that?!
They don't need to ask Google for data from other companies. They can compel them to provide the passwords or authentication codes which are stored on Google's servers. Or they could just ask for a list of which accounts have a saved password, so they know who to target next with an NSL.
I responded to
> Google could be requested to peer not just into the user's google account, but into accounts they have with other companies/organisations too
Your response to my response should somehow relate to that.
Also important to note, ADP is opt-in currently.
Warning: this blog post has meaningless marketing-speak. It starts by saying Android is about choice but instead of announcing the ability to set your own backup provider, it just says how Google's Android backup service works, which is wholly unrelated to that first sentence.
If you are talking about other data, Google don't have it encrypted even today.
Not end to end: https://www.wired.com/story/apple-end-to-end-encryption-iclo...
https://support.apple.com/guide/iphone/back-up-iphone-iph3ec...
https://support.apple.com/guide/icloud/view-and-manage-backu...
Does or should grandma care? No.
Should a political dissenter living in an oppressive regime think twice? Yes.
It's free, open source and has tons of great features.
So if I don’t pay money for things there’s not a service element, or a phone home to activate element, or other things that require an ongoing cost.
- Has a contractual obligation to keep your data secure.
- Accepts financial responsibility for data compromise.
- Carries insurance and bonding to back that responsibility.
- Does not require binding arbitration or forbid class actions.
- Has their employees bonded in the way bank employees are bonded.
Well?
We'd need a bunch of services to get to that level first to see any meaningful choice IMHO. I have no idea how that would happen.
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.
It has an option for encrypted, automated backups to Google or Nextcloud.
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.
No, that gets them the full way there. They have your 2FA codes, and if you use Chrome and opt into it syncing passwords for you (passwords.google.com), this gives them both pieces of the puzzle.
The sort of thing as a tech crowd would horrify many of us, but the public would largely go "oh neato".
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.
Then use across multiple devices.
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 wrote a simple CLI TOTP utility that works using an AES encrypted lookup table of secrets.
I piggybacked access to this off an unrelated web site and it is now readily available from any device if you have the decrypt key and know the URL.
If you already have a second E, just use the QR export/import feature.
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
tl;dr2 use offline TOTP or similar for real 2FA
Use WebAuthn with security keys.
Apple specifically says for Apple School Manager they want: a work email address that is not associated with an App Store or iCloud account, and has not been used as an Apple ID for any other Apple service or website
TOTP is cheap and much better 2FA than OTP over SMS.
Obviously, a YubiKey would be better, but Passkeys don't require you to carry an additional thing and are still more secure than TOTP apps.
I don’t like this idea. As a person whose had a phone break, like many others, tying auth to something so fragile should not be preferable. I’ll never forget my phone breaking and the process of trying to order a new one: the online shopping here, Shopee, demanded SMS 2FA (only option) which I needed to purchase a new phone so I found a different vendor but then my bank required SMS 2FA (only option) to do a transfer.
At least with these hardware security tokens, they’re pretty ‘dumb’ and often covered in epoxy or other weather-resistant material that makes them quite rugged & durable. Mine have gone through the wash and dangle from my motorbike’s keychain during the monsoons without issue.
> YubiKey
Please just use a generic term like “hardware security key/token” rather than endorsing a singular brand–especially one that is closed-source and looking to “go public” (https://news.ycombinator.com/item?id=35625065). If you think the closed nature of Google Authenticator is bad, consider an open hardware token option rather than a closed one.
https://dangerousthings.com/product/flexsecure/
Hard agree, though, TOTP >>>>>> OTP via SMS
Sms should never be used or offered, and needs congressional action to be stopped as a practice.
TOTP at least prevents turning Wireless carriers into security providers and is "good enough" for nearly everything.
And yes, WebAuthn/U2F is top of totem pole and should be something we're striving for nearly everything.
It's better than nothing.
I use yubikeys wherever I can, but I've got to admit that fetching all 5+ keys from their various locations and then replacing them every time I need to enroll in something gets old fast, especially when you get into locations like "buried in the mountains".
The phishability of TOTP is indeed a big problem but being able to just save the seed (theoretically, somewhere not next to the other credential) is really nice.
WebAuthn and friends are definitely an improvement, but it's not quite a perfect replacement yet.
Besides, even some banks still use SMS for 2FA at this point. TOTP would make a lot of sites more secure already.
I think I'll refrain from posting on topics about Google — clearly there is a huge pro-Google sentiment among HN readers and anything detracting from that gets instantly downvoted.
I will only use 2fa applications that do standard 30 second TOTP. Bonus points if it can set custom times and hash algos. A good application like this is Aegis Authenticator for mobile.
- 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.
- 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.
The actual complaint SEEMS to be:
> Google Authenticator backup isn't encrypted at rest on Google's Servers
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).
In general the linked post doesn't do a good job describing what they found and how they found it.
This is pretty common use for the term E2EE as far as I can tell. That all of the "clients" for which the encryption would be end-to-end for are all run by the same user is not really a big deal; I've seen it used similarly for things like "end-to-end encrypted notes" and that sort of thing. Example: https://standardnotes.com/
Encryption at rest is not really part of the discussion. There’s no way to verify client side that it is happening, and it does not prevent Google servers from seeing the plaintext backup.
> In general the linked post doesn't do a good job describing what they found and how they found it
Seemed pretty clear: they did MITM to bypass any transit encryption and saw the plaintext secrets being sent, and thus Google servers can see all the secrets.
Encryption at rest would NOT solve the problem being described here. Even if the data was encrypted both in transit and at rest, that does not mean that Google is incapable of getting access to the data. The data needs to be encrypted from the moment it leaves the device until the moment it arrives back on the user's device again (e.g. client to client E2EE), which is a stronger criteria than encryption in transit and at rest.