Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google Authenticator cloud sync: Google can see the secrets, even while stored

defcon.social

Post reply on HN
Print view View original

131–140 of 149 posts

Re: Google Authenticator cloud sync: Google can see the secrets, even while stored

#131

Post by TechBro8615 »

bipson wrote: post #130
TechBro8615 wrote: post #126

Earlier quoted context omitted.

Legality doesn't matter when the authorities pull out the magic National Security Letter, slap you with a gag order, and fine you an amount doubling from $50,000 per day until you comply.

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

My comment is referencing what was documented to happen during 2013: the NSA compelled tech companies to turn over user data under threat of jailing the executives and fining the company huge amounts.

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.

Re: Google Authenticator cloud sync: Google can see the secrets, even while stored

#132

Post by webmobdev »

trickstra wrote: post #64
patmcc wrote: post #45

It's a tradeoff. They could let (or require) a password be entered to encrypt/decrypt it on each device, but then people would be ticked off when they forget their password and can't recover their 2FA stuff. 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 pa…

I don't think Google will use those secrets to look into your other accounts, but they can be politely requested by some governments to divulge the secrets, and not tell you about it. Then those governments would have no problems looking into your other accounts. And I'm not talking only about the US government, other governments can have dubious standards for requesting user data, such as failure to parrot the "fact…

Exactly - one of the major reason American BigTech is so invasive today in collecting our personal data is because the US government has shown them how valuable it is for them. Project PRISM has evolved and is huge success ...

Re: Google Authenticator cloud sync: Google can see the secrets, even while stored

#133

Post by bipson »

TechBro8615 wrote: post #131
bipson wrote: post #130

Earlier quoted context omitted.

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

My comment is referencing what was documented to happen during 2013: the NSA compelled tech companies to turn over user data under threat of jailing the executives and fining the company huge amounts. 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 account…

Dude. Everything you said is correct, but:

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.

Re: Google Authenticator cloud sync: Google can see the secrets, even while stored

#134

Post by TechBro8615 »

bipson wrote: post #133
TechBro8615 wrote: post #131

Earlier quoted context omitted.

My comment is referencing what was documented to happen during 2013: the NSA compelled tech companies to turn over user data under threat of jailing the executives and fining the company huge amounts. 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 account…

Dude. Everything you said is correct, but: 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.

Well in that case, after rereading your comment I guess I agree with you. I don't think the government would deputize Google to effectively hack into other companies on their behalf. I wouldn't put it past them to ask for a backdoor into a user's device, but I doubt Google would comply with that (although there is precedent for Google remotely installing Covid tracking apps on devices in Massachusetts).

Re: Google Authenticator cloud sync: Google can see the secrets, even while stored

#135

Post by jqpabc123 »

Simplicitas wrote: post #121

Why don’t people use their own TOTP provider, like KeepassXC/Strongbox, storing the DB in an encrypted manner on a cloud of their choice. 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?

It's fairly easy to make your own TOTP provider.

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.

Re: Google Authenticator cloud sync: Google can see the secrets, even while stored

#136

Post by yencabulator »

makeitdouble wrote: post #73
Animats wrote: post #46

Is there anyone who operates an authentication service which: - 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?

Outside of the price issue, this service would also be a prime target go get compromised: I'd assume it would get the juiciest users, and national agencies would have the strongest incentives to backdoor it for later use. 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.

So, just like okta.com, used by lots of huge companies.

Re: Google Authenticator cloud sync: Google can see the secrets, even while stored

#137

Post by yencabulator »

dvzk wrote: post #105
imrehg wrote: post #91

Earlier quoted context omitted.

I guess the person meant this: encrypt-than-upload of backups with backup passkey managed by yourself, details e.g. in this blogpost: https://authy.com/blog/how-the-authy-two-factor-backups-work...

I suspect the vast majority of Authy backups use passwords trivially susceptible to brute-force attacks despite only 1000 (!!!) iterations of PBKDF2. If Authy wanted to do things right, it would generate local encryption keys instead of asking normies for file encryption passphrases.

argon2/scrypt with significantly larger costs sound like the right fix. Asymmetric crypto can make backing up still cheap, who cares if restoring takes 30 seconds.

Re: Google Authenticator cloud sync: Google can see the secrets, even while stored

#138

Post by dvzk »

yencabulator wrote: post #137
dvzk wrote: post #105

Earlier quoted context omitted.

I suspect the vast majority of Authy backups use passwords trivially susceptible to brute-force attacks despite only 1000 (!!!) iterations of PBKDF2. If Authy wanted to do things right, it would generate local encryption keys instead of asking normies for file encryption passphrases.

argon2/scrypt with significantly larger costs sound like the right fix. Asymmetric crypto can make backing up still cheap, who cares if restoring takes 30 seconds.

That would be a great improvement for technical users. But also consider that the target for Authy is the average mobile user. I’m not unconvinced that the typical backup password looks like S3cr3tP@s$w0rd, which no amount of key stretching will fix.
Post reply on HN