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

251–260 of 297 posts

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

#251

Post by simiones »

OtherShrezzing wrote: post #124
simiones wrote: post #17

Earlier quoted context omitted.

Yes, why the Slack or HR or interview etc. data would still exist while being inaccessible to the original owner is very strange. The article seems to take it as a foregone conclusion that those accounts should all be expected to still exist with all the business data, and I don't know if this is based on the author's experience, or it's just a way to make the vuln sound far more serious than it really is. On the oth…

>why the Slack or HR or interview etc. data would still exist while being inaccessible to the original owner is very strange Ever been in a company that's collapsed before? Nobody hangs around to shut down the WorkDay account when they've been told they're not getting paid for the last 29 days work.

I get that part, but I'm not sure why they would expire even later than the domain registration and the Google Workspace account. I would expect WorkDay or whoever to close/archive a non-paying account much earlier than that.

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

#252

Post by herczegzsolt »

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?

For example a call to the registered owner or contact person of the organizaton (not the user).

Any out-of-band communication should work which checks for the legal entity, not just something that eventually relies on DNS.

Alternatively, you can always just not let them access the old user, and create a new one instead.

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

#253

Post by the-rc »

delfinom wrote: post #225
radlad wrote: post #109

Earlier quoted context omitted.

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…

Yea "hd" doesn't work here. Users can make google accounts with corporate domains but without gsuite hosting attached. The same concern applies to just @gmail.com addys. Google has gotten big on nuking inactive accounts now, what stops similar openings where a person's inactive account gets recreated by an attacker and waltz his way into SSO systems? There's some corporate systems (usually benefits) that allow person…

Once a Gmail account is deleted, it can't be recreated by anyone, including the original owner.

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

#254

Post by jeroenhd »

andrewstuart2 wrote: post #13

This is more of a fundamental issue with the way we rely on DNS to secure *gestures wildly* all the things. The fact that domains can expire and be registered by someone new allows the new owner to do almost anything the old owner could have done when it comes to anything trusting email addresses, or anything else relying on DNS (ACME certs) for authentication. It's great for "do they own this right now" validation a…

With OIDC, that's what the `sub` identifier is for. Apparently, this changes for 0.04% of accounts (according to "a staff engineer at a major tech company" quoted in the article), but it's what Google tells you to use to identify a user. When a domain expires and you re-register for OIDC with Google, the `sub` claim will differ and the application should refuse your login attempt.

If the `sub` claim does indeed change for no good reason, that's a bug on Google's side, but I can't find anything online to corroborate that claim. The sub value changing when accounts are recreated could be a pain for large companies to deal with, but other than that the solution is pretty simple.

There are no good alternatives for email addresses that are also human readable, unfortunately. Some web3.0 cryptocurrency projects do encryption based authentication that solves this problem (but makes your accounts impossible to recover if you lose your key file). Passkeys/WebAuthn also try to solve this problem by foregoing the entire username requirement, but websites still ask for email addresses just in case.

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

#255

Post by jeroenhd »

paxys wrote: post #113

It's crazy just how little effort it takes to get a "Google = bad" article to the top of HN. There is no vulnerability in Google OAuth. This is exactly how every OAuth server is supposed to work. If you take over a domain, you automatically own every email address in that domain, and thus whatever external account relies on that email for login. Heck the result would be the same even if that service didn't use Google…

> If you take over a domain, you automatically own every email address in that domain, and thus whatever external account relies on that email for login

Actually, if both sides implement OIDC+OAuth2 correctly, you don't. The subject claim (`sub`) of the attached Google account doesn't get reused when a new owner re-registers the domain with Google.

The article claims that the supposedly immutable `sub` field changes too often, though, and that would be a problem Google needs to fix. The source is an unnamed developer mentioned at https://youtu.be/yIutY_X2FcU?t=20617 who encounters issues with custom domain users, with the `sub` field changing weekly in some cases.

Sure, you can create new accounts when you take over a domain and even fake all the old accounts if you have a list somewhere, but you shouldn't be able to access all of the accounts authenticated with OIDC unless you break into the Google Workspace account.

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

#256

Post by jeroenhd »

nixosbestos wrote: post #176
anon84873628 wrote: post #83

Earlier quoted context omitted.

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…

The slides claim that this problem happens almost 600 times per week. There's no way it makes sense to manually validate all of those sessions.

The secure thing would be to kick those users out and tell them to go figure out with Google why their account IDs keep changing. The easy and more profitable solution is to just use the email address as an account ID and keep the customers.

Google did re-open the bug so I think there may be something wrong on Google's side, but for 99% of companies just using the `sub` value like it's intended to won't cause anyone any headache.

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

#257

Post by jeroenhd »

bhartzer wrote: post #217

I don't think this has anything to do with Google's OAuth. This issue is literally with every single expired domain name out there. All one has to do is register the expired domain and look at all the emails sent to that domain. Granted, Google "could" do something, but I don't think it's Google's responsibility to police expired domain names. What am I missing here?

Google promises to use a different `sub` claim for every account, even if you reuse the domain name. However, according to the talk, the `sub` claim isn't stable in normal scenarios, so developers don't use that like they're supposed to.

Google should fix the `sub` problem if the problem is on their side (and not, for instance, related to user accounts impersonation or recreated user accounts, which are expected to fail this check). Everyone integrating with Google should use the `sub` claim like they're supposed to.

Of course this approach doesn't help if a domain admin can recover the original workspace account (rather than simply re-registering the domain with Google), but that can easily be solved by not having the domain admin accounts use the domain they're hosted on.

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

#258

Post by [deleted] »

jeroenhd wrote: post #254
andrewstuart2 wrote: post #13

This is more of a fundamental issue with the way we rely on DNS to secure *gestures wildly* all the things. The fact that domains can expire and be registered by someone new allows the new owner to do almost anything the old owner could have done when it comes to anything trusting email addresses, or anything else relying on DNS (ACME certs) for authentication. It's great for "do they own this right now" validation a…

With OIDC, that's what the `sub` identifier is for. Apparently, this changes for 0.04% of accounts (according to "a staff engineer at a major tech company" quoted in the article), but it's what Google tells you to use to identify a user. When a domain expires and you re-register for OIDC with Google, the `sub` claim will differ and the application should refuse your login attempt. If the `sub` claim does indeed chang…

[deleted]

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

#259

Post by ForHackernews »

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…

> Google already recognizes that fact, by setting a different value in the "sub" field of the claim it returns

Then Google is doing the right thing. It's incumbent on the relying party to enforce its own authorization policies based on the information the authorization server provides.

Google says, "here's bob@example.net ", oh now "here's bob@example.net "

Google can't save consumers from their own negligence.

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

#260

Post by lovasoa »

Does anyone here know more about the unreliability of Google's sub claim? I am using it, and have never had issues with it, but this post seems to just dismiss it without more details.

When does Google change the subject of a token for a given user account?

Post reply on HN