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

Google’s OAuth login doesn’t protect against purchasing a failed startup domain

trufflesecurity.com

Post reply on HN
Print view View original

231–240 of 297 posts

Re: Google’s OAuth login doesn’t protect against purchasing a failed startup domain

#231

Post by necovek »

anon84873628 wrote: post #226
jpc0 wrote: post #157

Earlier quoted context omitted.

Sue lost hee phone, she used KeePass for everything and didn't back it up. She get some support from IT, what do they do to solve Sue's problem? They reset her password and 2FA and have her redo them. She probably gets a lecture about backups or she spurns a brand new company policy that "Everyone should now use LastPass and nothing else is supported". If they as administrators cannot do that, Sue has now lost signif…

What does this have to do with the scenario above? Of course you can reset the corporate SSO account as many times as you want. The point is that federated apps with a password reset flow should have some sort of MFA.

It defeats the purpose of the first S in "SSO": it's not a Single Sign-On, and for Sue in GP's example, after losing access to her MFA, she can't access federated service data, nor can the domain operators restore her access.

Re: Google’s OAuth login doesn’t protect against purchasing a failed startup domain

#232

Post by necovek »

scarface_74 wrote: post #110
anon84873628 wrote: post #106

Earlier quoted context omitted.

SSO should stop working when the IdP org is disabled/deleted. IdPs should not allow the org to be resurrected based solely on domain ownership alone. And if a new org is created with the same domain, the SP will need to be reconfigured with new OAuth client creds, and should be relying only on the `sub` claim anyway. Any accounts you need after leaving a company should be tied to your personal email.

My brokerage account could be accessed by both. I agree that is how it should work. But my brokerage account provider is never told to disable access via my IdP. It’s up to my former IdP to not do something stupid like giving someone else my old email address.

It's not IdP's responsibility to "fix" the internet.

Just like someone can buy a home and will get mail targeting a previous owner, the same happens with domain names and emails.

Domains are, however, much cheaper and more abundant, so it happens more often.

Re: Google’s OAuth login doesn’t protect against purchasing a failed startup domain

#233

Post by necovek »

Assuming most of the problem is that federated services only rely on email address from OidC login, I wonder if Google could start offering user+unique-workspace-id@company.domain as the email address for any new workspace/user/federated login? Obviously, Google needs to control "unique-workspace-id".

Does not solve it for existing customers and any federated service they logged into, though if included alongside the simple email, federated services could gradually move to it and announce once they are "ready" so workspace admins can configure them to start accepting only new, safe email addresses.

Re: Google’s OAuth login doesn’t protect against purchasing a failed startup domain

#234

Post by jbmsf »

loginatnine wrote: post #40

I really don't understand here, the proper way to use Google's OpenID implementation to authenticate someone is to use the `sub` claim. Don't use the email, don't verify it yourself, use the `sub` claim. It's a known fact and is properly documented[1]. If the `sub` changes, it's because it's not necessarily the same person so have a flow ready for that. It could be an employee left and came back, a domain change, an…

There's a reason this happen though. Whether you like it or not and regardless what the standards say, people want a technology that matches with the identifiers they want to use (eg email) and not whatever opaque value happens to be in the sub claim.

I don't like blaming users for wanting something sensible.

Re: Google’s OAuth login doesn’t protect against purchasing a failed startup domain

#235

Post by j16sdiz »

russelg wrote: post #215
saguntum wrote: post #55

Earlier quoted context omitted.

Yeah, I'm not really clear on the vuln. It sounds like clients don't validate sub claims because they are unstable? Google's docs say they should. When I first read the post, I thought that maybe Google was reusing sub claims when they shouldn't, but on a closer read, maybe it's the opposite problem - that the sub claim is changing when it should not change? From the article - “The sub claim changes in about 0.04% of…

I ran into this when implementing OIDC at work. One of my teammates wasn't able to login even though he just linked his google account. Turns out based on which browser session he was using, the same google login was giving a different sub. Super weird behaviour.

very skeptical about this - I believe they are two accounts.

It is possible to create two google account linked with same email address.

I think I need more proof they are actually same account. For example, changing the profile pic in one session is reflected in another session.

Re: Google’s OAuth login doesn’t protect against purchasing a failed startup domain

#236

Post by j16sdiz »

deathanatos wrote: post #230

> According to a staff engineer at a major tech company: > “The sub claim changes in about 0.04% of logins from Log in with Google. I've had a staff SWE also claim to me that they generated colliding UUIDv4s, and a separate staff SWE who worked in GIS claim that circles only exist in map projections and they're always distorted, and that you cannot have a circle IRL, nor project it onto a projection. Neither's attent…

> I've had a staff SWE also claim to me that they generated colliding UUIDv4s,

UUIDv4 is random. Could be a bad PRNG, or just very very very bad luck.

> and a separate staff SWE who worked in GIS claim that circles only exist in map projections and they're always distorted, and that you cannot have a circle IRL, nor project it onto a projection.

It is insanely difficult to project circles. Most of time we just pretend it never exist.

Re: Google’s OAuth login doesn’t protect against purchasing a failed startup domain

#237

Post by patmcc »

tsimionescu wrote: post #182
patmcc wrote: post #125

Earlier quoted context omitted.

>>>The problem is that the original DankStartup has a Google account that they create in #1, and Google goes around telling other sites (via Auth) "this is user X from company Y". Google is telling other sites that it's bob@DankStartup.com - isn't that true? Isn't this on DankStartup to close down operations cleanly?

It's a different bob@DankStartup.com, and in fact a completely different DankStartup.com. Google shouldn't conflate the two. There are exactly 0 situations where the current behavior is useful. There is no reason whatsoever to have the exact same auth info for two Google accounts that happen to have the same domain.

>>>It's a different bob@DankStartup.com, and in fact a completely different DankStartup.com. Google shouldn't conflate the two.

Does Google have any reliable way of knowing that?

>>>There are exactly 0 situations where the current behavior is useful. There is no reason whatsoever to have the exact same auth info for two Google accounts that happen to have the same domain.

I have a personal google workspace account with a few domains. At some point I might want to spin one off to be its own (maybe I start a company). But I'd still expect pat@mydomain.com to keep working throughout. So that's 1 situation.

Re: Google’s OAuth login doesn’t protect against purchasing a failed startup domain

#238

Post by toast0 »

deathanatos wrote: post #230

> According to a staff engineer at a major tech company: > “The sub claim changes in about 0.04% of logins from Log in with Google. I've had a staff SWE also claim to me that they generated colliding UUIDv4s, and a separate staff SWE who worked in GIS claim that circles only exist in map projections and they're always distorted, and that you cannot have a circle IRL, nor project it onto a projection. Neither's attent…

> I've had a staff SWE also claim to me that they generated colliding UUIDv4s, and a separate staff SWE who worked in GIS claim that circles only exist in map projections and they're always distorted, and that you cannot have a circle IRL, nor project it onto a projection.

The claim about circles I don't know. It depends on what exist means, and I don't know what it means to have a circle in real life, and likely don't care. I can only draw a rough approximation of a circle, and that's been fine for me.

Generating a colliding UUIDv4 seems pretty simple though; if you have a broken enough random generator setup and manage to run it without seeding, especially if it was in the times where it was pretty easy to run a virtual machine with totally broken random (virtio-random was developed for a reason), and spawned a bunch of virtual machines in very similar conditions. You can no true scotsman your way out of this by declaring that a broken system, but from inspection, I don't know how you can determine if a given UUIDv4 was generated with proper or broken random techniques. See also Debian Security Advisory 1571-1 [1], and similar issues where random values that were intended to be secure turn out to be predictable. It's a plausible claim. But that doesn't mean a claim by a 'staff engineer' is default plausible. It's just an appeal to authority of a title that doesn't mean a lot.

[1] https://lists.debian.org/debian-security-announce/2008/msg00...

Re: Google’s OAuth login doesn’t protect against purchasing a failed startup domain

#239

Post by patmcc »

cortesoft wrote: post #146
patmcc wrote: post #125

Earlier quoted context omitted.

>>>The problem is that the original DankStartup has a Google account that they create in #1, and Google goes around telling other sites (via Auth) "this is user X from company Y". Google is telling other sites that it's bob@DankStartup.com - isn't that true? Isn't this on DankStartup to close down operations cleanly?

Sure, but DankStartup failed and doesn’t exist anymore. If I am just a lowly employee, I can’t force the failed startup owners to properly shutdown, and now my payroll information is available to hackers. What is my remedy?

Probably sue the failed startup owners for negligence?

If DankStartup left all your HR files lying around in their office and the guy who bought it five years later found them, well, DankStartup should have shredded them. It'd sure be nice if the cleaners shredded them for you, but I wouldn't count on it (nor make them liable).

Re: Google’s OAuth login doesn’t protect against purchasing a failed startup domain

#240

Post by otabdeveloper4 »

danudey wrote: post #59
stackghost wrote: post #7

It's not 100% clear to me, from reading TFA, what the actual vuln is. Suppose DankStartup folds and I, being a morally-dubious sort of fellow, purchase dankstartup.net which I then use to sign into DankStartup's O365, or DankStartup's ChatGPT as a DankStartup employee. Isn't that a failure on DankStartup's part, to not shut down their business accounts? And isn't it also a failure on e.g. Microsoft or OpenAI's parts,…

Well, think about it this way: 1. I create DankStartup and my company uses Google workspaces and Google auth for a bunch of stuff, like payroll. 2. DankStartup goes under and we close our Google accounts/let our domain lapse. 3. Someone else buys DankStartup.com, sets up a Google workspace, and attempts Google auth to log into stuff, and it works. The problem is that the original DankStartup has a Google account that…

I don't see the problem here.

We've already settled on DNS being the auhoritative authentication key for everything. If you bought the domain then you've bought the corporate identity. It's working as designed.

Post reply on HN