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

241–250 of 297 posts

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

#241

Post by Salgat »

patmcc wrote: post #125
danudey wrote: post #59

Earlier quoted context omitted.

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…

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

Login credentials are more than just the email used, and should not be conflated with identity. To be honest I'm surprised google isn't using a uuid tied to the account for the identity given to others, especially since internally google knows and treats it as a separate account that just happens to have the same e-mail. The e-mail should only be used as metadata for contact info.

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

#242

Post by ycombinatrix »

verdverm wrote: post #228
ycombinatrix wrote: post #178

Earlier quoted context omitted.

shame, ICANN sucks

I would argue the crypto bros are worse

crypto bros are annoying but at least they're doing their own thing. ICANN is actively screwing us.

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

#243

Post by ycombinatrix »

nixosbestos wrote: post #173
Timshel wrote: post #44

Earlier quoted context omitted.

It all depends on how true this statement is: > “The sub claim changes in about 0.04% of logins from Log in with Google. For us, that's hundreds of users last week”.

Exactly. How is there an entire alarmist article and 165 comments on this thread. This comment, and it's legitimacy/factualness, is the only thing worth discussing . `sub` _IS_ the immutable reliable identifier. If it's not, (1) I want to see actual proof, not an anonymous rando (sorry, but this thread re-inforces how little I trust context-less comments like that), and (2) I'd want to hear a convincing argument that…

agreed. the real story is that people are ignoring `sub` out of convenience and creating a security hole.

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

#244

Post by tsimionescu »

freedomben wrote: post #214
tsimionescu wrote: post #182

Earlier quoted context omitted.

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.

Whoever has access to the inbox and account for bob@DankStartup.com is bob@DankStartup.com. If Google was being asked if the SSN for bob is 123-45-6789 and they were saying yes, then I would agree that's an issue, but all Google is saying is "this person can authenticate to our services as bob@DankStartup.com" and that is true.

But the new owner does not have access to the inbox or any other account info of the old bob@DankStartup.com. They're completely separate accounts, with the same email address. Plus, Google already recognizes that fact, by setting a different value in the "sub" field of the claim it returns (though per the article, it seems that may not work properly).

And legal relations just don't work this way. A person is who they are, and it is that person who has legal access to whatever data was stored in their Slack. Another person who happens to have the same email some time later doesn't have any right whatsoever to that same data. OAuth exists to help secure this type of legal relation, not to establish a completely fictitious identity.

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

#245

Post by tsimionescu »

patmcc wrote: post #237
tsimionescu wrote: post #182

Earlier quoted context omitted.

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 wi…

> Does Google have any reliable way of knowing that?

Yes, Google knows this is a new Google Workspace account using the same domain as the old one.

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

That should be a separate feature of Google Workspace, where you can transfer an identity, it shouldn't be automatic. And it shouldn't even be tied to the domain name. If you decided that you prefer the domain to be pat@mybetterdomain.com, you'd still want to have access to the old Slack conversations or whatever. Conversely, if you lost access to the mydomain.com domain (say you forgot to renew it, or some legal entity sued for it because it was their trademark or whatever), I'm certain you wouldn't want the new owners to then have access to your Slack or any other data, just because they have the same domain name.

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

#246

Post by tsimionescu »

tart-lemonade wrote: post #195
tsimionescu wrote: post #191

Earlier quoted context omitted.

This is very much a critical flaw in systems which rely entirely on email or domain names as the sole security factor. OAuth itself is flawed in that it allows this terrible practice, though to be fair it does discourage it. Google's specific OAuth solution encourages this compromised practice even more, because the only identifier it provides for a user group is the domain name associated with the account (in the "h…

That's a really good point. Perhaps the protocol should be expanded with an explicit identifier unique to an extant legal entity (or string of identifiers, to account for ownership changes like acquisitions), so it would be easy for SSO-enabled applications to keep previous tenants' data safe from someone who just buys the domain later on. Of course, this would still rely on the provider: it might be a great solution…

I don't think it would need to go that far. Simply tying it to a Google Workspace account and not to the domain should be plenty good enough. Google knows if example.com changes between being associated with Google Workspace A to Google Workspace B. But it's not including that info in the OAuth claims.

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

#247

Post by nodamage »

tsimionescu wrote: post #174
nodamage wrote: post #163

Earlier quoted context omitted.

What I'm suggesting is if you were able to pre-configure Slack to only allow logins for valid users from Google Workspace X, then even if someone creates a new workspace Y with the same domain, Slack would still be checking against workspace X. (And similar for non-Google based identity providers.)

And people are telling you that this is not possible with the Google public OAuth API. When Slack asks Google's public OAuth instance if user abc@example.com is valid, Google checks with the Google Workspace associated to example.com, and returns to Slack a response saying "yes, that user is valid, here is more information from example.com". This can be the same Workspace or another one, Google isn't really telling S…

> And people are telling you that this is not possible with the Google public OAuth API.

Yes I understand, however it is possible to integrate Slack and Google SSO in such a way that it checks that the user belongs to the correct workspace, correct? Either via the SAML integration (https://support.google.com/a/answer/6357481) or an internal Google OAuth integration? The purpose of the public Google OAuth API as opposed to the previous two options is to allow logins from non-workspace or cross-workspace Google accounts, correct?

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

#248

Post by nodamage »

radlad wrote: post #156
nodamage wrote: post #150

Earlier quoted context omitted.

I don't think so, but please go ahead and clarify if that is the case.

Maybe you can clarify what part of the linked comment didn't make sense? It's a bit hard to make out where the confusion is if the above comment didn't help clarify.

If I'm understanding your comment correctly there are three different ways to connect Google SSO to your application:

1. SAML. This avoids the issue because certificates need to be exchanged between Google and your application, but an attacker that recreates a duplicate workspace using your domain won't have access to those certificates. Only users from your workspace will be allowed to login.

2. A custom Google OIDC IdP configured for internal access only. This also avoids the issue because a secret key is required to set this up and the attacker won't have access to that key. Again, only users from your workspace will be allowed to login.

3. The public Google OAuth API which will allow any Google user from any workspace (or non-workspace users) to login to your application.

Is this correct?

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

#249

Post by jsnell »

Salgat wrote: post #241
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?

Login credentials are more than just the email used, and should not be conflated with identity. To be honest I'm surprised google isn't using a uuid tied to the account for the identity given to others, especially since internally google knows and treats it as a separate account that just happens to have the same e-mail. The e-mail should only be used as metadata for contact info.

> To be honest I'm surprised google isn't using a uuid tied to the account for the identity given to others

But they are providing a unique, stable, never reused identifier tied to the account, as has been mentioned a number of times in this thread. It's the "sub" field[0], whose entire purpose is to be the unique identifier for tying the IDP's data to the RP's data.

What they're not doing is to provide that unique id in the "email" field, because the purpose of the email field is to contain the email address. The documentation even specifically tells not to use it as the primary identifier.

> The e-mail should only be used as metadata for contact info

Indeed. But that's up to the relying party. The only way to prevent them from checking the wrong field would be to not provide them the email address at all, even when they're explicitly requesting it.

[0] https://developers.google.com/identity/openid-connect/openid...

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

#250

Post by dinoqqq »

otabdeveloper4 wrote: post #240
danudey wrote: post #59

Earlier quoted context omitted.

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.

The flaw is the fact that companies go bankrupt and their data should die with them. In case of bankruptcy it might be impossible to hold on to your DNS and therefore risking old company data leaking.
Post reply on HN