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

171–180 of 297 posts

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

#171

Post by ycombinatrix »

chavesn wrote: post #153
herczegzsolt wrote: post #70

Earlier quoted context omitted.

In my opponion, all of those cases very well justify a manual check, or some sort of extended identification before the user is let in. It indicates a deeper cultural issue of "convenience/profit over security" if those are sufficient reasons to not check the sub parameter.

> all of those cases very well justify a manual check, or some sort of extended identification before the user is let in. Just curious, what would that check look like that's not open to the same vuln?

"Your account seems to have changed hands and is locked for your security.

The person paying for your subscription must contact us to verify your account is still legit."

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

#172

Post by jedberg »

grepfru_it wrote: post #136
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?

Part of my company dissolution process is to renew the domain name for 10 years to prevent exactly this

Is the hope that this sort of attack is just less useful in 10 years? What happens after 10 years?

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

#173

Post by nixosbestos »

Timshel wrote: post #44
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…

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 ... `sub2` would actually be less mutable.

Threads like this make me really question other peoples' general comprehension skills.

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

#174

Post by tsimionescu »

nodamage wrote: post #163
radlad wrote: post #155

Earlier quoted context omitted.

I think you may be a bit confused about the players here. When you use Google OAuth to login, it _is_ your identity provider, and it is reporting to Slack that the user exists. Google is reporting the user exists because it exists in the Google Workspace directory. You use this as your source of truth for provisioning users, and they automatically get access to all of your company's apps. The problem is that even tho…

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

Now, there is another field called "sub", that should be a unique ID for the Google Workspace or the specific account, but it seems that this is not always stable, per the article, so people integrating with Google OAuth don't trust it.

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

#175

Post by mikeryan »

PKop wrote: post #64
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…

Yes but he's saying the data on 3rd-party websites should be deleted by the failed startup when they shutdown not just left to sit there.

There’s an interesting question on service providers responsiblity who use Oauth for primary auth.

Should they reset all access to a company account if a domain transfers or becomes publicly available?

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

#176

Post by nixosbestos »

anon84873628 wrote: post #83
erincandescent wrote: post #21

> To resolve this issue, Google could implement two immutable identifiers within > its OpenID Connect (OIDC) claims: > 1. A unique user ID that doesn’t change over time. > 2. A unique workspace ID tied to the domain. 1. is the OIDC `sub` claim! I strongly suspect that in those 0.04% of accounts where the anonymous quoted engineer reports that the `sub` claim changed, what actually happened was some provisioning/onboa…

1. Yep, your hypothesis seems likely. Consumer gmail addresses can't be used again after they are deleted, but it seems in Workspace orgs they can be reused/reassigned after 20 days: https://support.google.com/a/answer/33314?hl=en&co=DASHER._F... If services are not respecting the `sub` claim in this case, then they are giving the new Google account access to the old account's data. Companies probably wouldn't compla…

Reinforcing the face-palm at the heart of this, which is that anyone deciding to you know, just use email instead of asking why an immutable ID changed... just probably enabled information leakage. Seriously, I'm so thankful that my colleagues would be principaled about this and ask questions instead of just doing something to make it "work". Where "work" means some GSuite user probably logged into some other defunct GSuite user's RP-account.

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

#177

Post by hansvm »

This feels similar in spirit to some service providers (*cough* Atlassian -- especially bad when they acquire other companies and push that bullshit on previously functional authentication systems) using ownership of a domain to assert ownership of an account using that domain.

E.g.:

1. You create an account using an email associated with a domain.

2. The domain owner coughs up their protection money to Atlassian and proves ownership of the domain.

3. Your password-protected account is assigned to the domain owner. Your password and 2FA invalid. The domain owner can access your private data without your password and 2FA.

Both TFA and the thing I described rely on broken, simplistic views of "domain ownership == account ownership".

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

#178

Post by ycombinatrix »

verdverm wrote: post #78
maerF0x0 wrote: post #71

Seems like we need a chain of custody for domains, not just current ownership. Kinda like real estate. And then accounts are tied not just to the ownership state, but also the ownership instance ID. Just don't tell the web 3.0 folks cause I don't necessarily mean a blockchain.

Web 3 already tried this, it was called Handshake. I think their downfall is they wanted to replace ICANN / DNS rather than work with and alongside the current system.

shame, ICANN sucks

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

#179

Post by tsimionescu »

anon84873628 wrote: post #94
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…

It seems there are two possible problems. The first is whether taking over a lapsed domain allows you to takeover an existing Google Workspace (or Cloud Identity) organization. This it what houses the corporate email accounts and OAuth client registrations. If Google allows this scenario then the linked account takeover is simply one symptom / side effect among many. TFA is not clear on whether this step actually hap…

> That said, I'm still not clear how the second problem manifests if the old OAuth client creds (housed in the old Workspace org id) are invalid.

As far as I understand, this is not a necessary step. The SP is configured to trust Google's public OAuth IdP, not a specific Google Workspace account. So there are no special secrets shared between the old Google Workspace account and, say, Slack. The Slack org trusts any user that Google's public OAuth IdP says is a valid user in the example.com domain. Slack doesn't have to do any MFA for these accounts, they trust Google did that already.

Now, you may not be able to access the Slack org admin account in this way, say to add/remove users or delete the org. But you can access all of the other information that any random employee in the org could access back when it was setup, including a list of all other users in the org.

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

#180

Post by chavesn »

ycombinatrix wrote: post #171
chavesn wrote: post #153

Earlier quoted context omitted.

> all of those cases very well justify a manual check, or some sort of extended identification before the user is let in. Just curious, what would that check look like that's not open to the same vuln?

"Your account seems to have changed hands and is locked for your security. The person paying for your subscription must contact us to verify your account is still legit."

Right, and how would you further verify “the person paying for your subscription”?
Post reply on HN