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

271–280 of 297 posts

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

#271

Post by Terretta »

radlad wrote: post #109
stackghost wrote: post #96

Earlier quoted context omitted.

>Then, the impostors in step #3 create a different google account with the same domain, and Google says "yeah, these are definitely the same guys as before", even though Google is fully capable of discerning that that is not the case; these are different people with a different workspace account, different names, different payment information, and so on, but Google is saying that if you're holding the domain you are…

Traditionally, SAML / OIDC trust is established using public/private keypairs. Each IdP/SP pair gets a unique combination. In this case, a domain changing hands would not allow the new owner to gain access to the old owner's accounts. In the case of Google OAuth, it's possible to forego this in order to allow any Google user from any Google workspace to login to your application. See the distinction between "public a…

> Google instructs you to look at the "hd" parameter, specific to Google, to determine the Google Workspace a given user belongs to for security purposes.

Saving a click: "hd" means "hosted domain"

hd — The domain associated with the Google Workspace or Cloud organization of the user. Provided only if the user belongs to a Google Cloud organization. You must check this claim when restricting access to a resource to only members of certain domains. The absence of this claim indicates that the account does not belong to a Google hosted domain

I can see value to that being a human readable string, and can see the value of "example.com" being able to be used to SSO for employees of both Example Inc. 1.0, and Example LLC 2.0.

That said, does seem an "hduuid" could be available for those who care, but mysteriously don't care enough to cancel their other SaaS relationships that use OIDC or SAML SSO.

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

#272

Post by patmcc »

tsimionescu wrote: post #244
freedomben wrote: post #214

Earlier quoted context omitted.

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

So why isn't it on Slack to address this (or not use OAuth, if it can't)? Google doesn't verify the actual legal person behind an email address, whether it's through gmail or google workspace, nor would we want/expect them to.

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

#273

Post by patmcc »

tsimionescu wrote: post #245
patmcc wrote: post #237

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

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

I agree it knows that, but it doesn't know:

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

How should it verify that? Should it? If you buy a domain that was used ten years ago, do you want google to say "well, we can't let you use contact@newDomain.com, someone used it previously and it may be confusing".

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

Maybe nobody should be using domain name and/or email address as authentication, but that ship has sailed in 100 different ways.

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

#274

Post by nodamage »

tsimionescu wrote: post #188
nodamage wrote: post #122

Earlier quoted context omitted.

I agree, I don't think this is a problem with Google's Oauth implementation, it's a problem with the service providers who authenticate users via the mere existence of an email address ending in @company.com without checking if the email address actually belongs to an active employee. If, when you logged into Slack via Google Oauth with the email address user@company.com, Slack checked with company.com whether user@c…

First of all, the whole point of SSO is that the only and final source on who are the valid active users is the IdP, in this case Google's public OAuth instance. If the IdP says that the current request is coming from the real user1@example.com, you give them access. And Google's public OAuth instance will confirm this even if the current Google Workspace associated with example.com is a different one than a few mont…

Google's public OAuth is intended for situations where you want to allow anyone with a Google account to login to your application, regardless of workspace. Given that, it is not a Google OAuth vulnerability that a user can login to your application using a Google account from a different workspace.

If you want to integrate Google SSO into your application and restrict logins to a specific workspace, there are other options you can use that will actually check if the user belongs to that workspace (SAML or internal OAuth).

To the extent that service providers are using Google's public OAuth and then trying to read the domain name out of the returned ID token in order to restrict logins a specific Google workspace, they are using Google's public OAuth instance for a situation it was not intended for because domain names do not map 1:1 to workspaces. However that is a vulnerability on the service provider's side, not Google's.

To the extent that a service provider offers Google SSO integration via Google's public OAuth but also via workspace restricted options, if a company selects the former instead of the latter then the responsibility for the vulnerability is on the company's side. (Slack, for example, offers both because there are some Slack groups where allowing access from any Google account makes sense, and other groups where you would want to restrict access to Google accounts from a specific workspace.)

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

#275

Post by tshaddox »

jbmsf wrote: post #234
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.

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

Are you saying that it's sensible to want email address ownership (and thus domain name ownership) to be permanently unchangeable?

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

#276

Post by tshaddox »

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…

> There is a simple explanation here: Your staff SWE is wrong. `sub` is the claim you're looking for.

Or perhaps it's actually happening 0.4% of the time. Maybe a few companies have some weird process that results in them routinely deleting accounts and creating new ones on the same email address.

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

#277

Post by radlad »

nodamage wrote: post #270
SAI_Peregrinus wrote: post #262

Earlier quoted context omitted.

No, there's no way to check which workspace is in use, just that the domain matches. That's the problem.

Only if you use the Google public OAuth integration. If you instead use the SAML integration with Slack as described in the link above you don’t have this problem.

Bingo! Now looking back to your original comment, this is what I was trying to clarify:

> I agree, I don't think this is a problem with Google's Oauth implementation, it's a problem with the service providers who authenticate users via the mere existence of an email address ending in @company.com without checking if the email address actually belongs to an active employee.

It's a problem with Google's public OAuth implementation when used for private workspace accounts, despite Google's docs stating that this is a valid use. :)

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

#278

Post by nodamage »

radlad wrote: post #277
nodamage wrote: post #270

Earlier quoted context omitted.

Only if you use the Google public OAuth integration. If you instead use the SAML integration with Slack as described in the link above you don’t have this problem.

Bingo! Now looking back to your original comment, this is what I was trying to clarify: > I agree, I don't think this is a problem with Google's Oauth implementation, it's a problem with the service providers who authenticate users via the mere existence of an email address ending in @company.com without checking if the email address actually belongs to an active employee. It's a problem with Google's public OAuth im…

> despite Google's docs stating that this is a valid use. :)

I don't think Google's docs actually say this. I assume you are referring to the "hd" claim, but that only says:

"The domain associated with the Google Workspace or Cloud organization of the user. Provided only if the user belongs to a Google Cloud organization. You must check this claim when restricting access to a resource to only members of certain domains. The absence of this claim indicates that the account does not belong to a Google hosted domain."

It does not say you can use this claim to restrict access to members of a certain workspace, only for a certain domain.

I think certain service providers might have made the assumption that if a user belongs to a certain domain that also means they belong to a certain workspace, but that is clearly not a valid assumption.

I think that Google's public OAuth integration is only intended for use in situations where you want to allow logins from any Google account, regardless of workspace membership, and if you want to restrict logins to Google accounts belonging to a specific workspace, you are supposed to use one of the other integrations.

Given all that, I still do not think this is a problem with Google's OAuth implementation. Instead it is a problem with service providers who have incorrectly used the wrong type of Google SSO integration. Or in the case of service providers that offer multiple Google SSO integration options (like Slack), it is a problem with the company for selecting the wrong one.

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

#279

Post by ticulatedspline »

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…

Yes this is not a "Google" problem so much as a "Your SaaS application is literally doing it wrong"

Having worked on a lot of SSO integrations I can say that everyone does it wrong.

I will also say that there is a super scary aspect to the sub claim (in general). It should be pairwise tied to the SP's integration, so if you only use google for auth, and for some reason you lost your google dev account and had to set up a new one you would drop credentials from 100% of your users.

for google I don't know if you can scope for the account ID (the opaque unique identifier) since that could expose privacy issues via cross integration tracking. But that's basically the fix. if you had the unique, immutable, opaque account identifier and matched on that this wouldn't work since buying a domain and setting up that email should result in a new account with google.

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

#280

Post by dragonwriter »

patmcc wrote: post #239
cortesoft wrote: post #146

Earlier quoted context omitted.

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

> Probably sue the failed startup owners for negligence

The owners generally aren't liable (assuming or corp or LLC), and if the company would have been liable, that liability probably died with the firm.

Post reply on HN