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

281–290 of 297 posts

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

#281

Post by dragonwriter »

DrillShopper wrote: post #165
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?

In a rational world the remedy would be to sue Google for exposing your payroll information.

Google is neither the party holding the payroll information nor the party that chose to make it available on terms that are insecure against loss of control of the domain, why would it be rational for them to be liable?

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

#282

Post by [deleted] »

PeterFBell wrote: post #80
PKop wrote: post #64

Earlier quoted context omitted.

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.

He's right, but having failed a number of times, after you've put all your savings into the business, fired all your team, notified and disappointed all of your investors and customers, helped your team find new gigs, filed all the dissolution paperwork, handled all the taxes, disposed responsibly of all of the assets and you now find yourself out of work and often out of cash, occasionally you'll forget to jump thro…

[deleted]

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

#283

Post by nixosbestos »

jeroenhd wrote: post #256
nixosbestos wrote: post #176

Earlier quoted context omitted.

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

1. The slides cite an anonymous, context-less, singular sentence claims that they change. With no indication of why they changed, or if that change was valid.

2. The sub can change, while keeping the same email, because it is in fact a different user. Just using the email is categorically wrong.

Again, so much hysterics, and I have serious doubts about the, thus unsubstantiated, entire premise.

Let me be more clear, I _do not believe that claim at all_. I find no other evidence of it. I've worked with RPs that allow Google auth and similarly have never experienced this or heard of it happening.

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

#284

Post by deathanatos »

j16sdiz wrote: post #236
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 preten…

> or just very very very bad luck.

You're underestimating the odds. The odds aren't "bad luck", the odds are "statistical impossibility". Literally any other explanation holds with orders of magnitude higher certainty.

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

Open Google maps, find the equator. That's a circle, rendered on a projection. (But far from the only example possible.)

(And lest I get more objections, a perfectly spherical earth was also an assumption of this assertion that circles don't exist. My coworker attempted to draw/show a circle onto an actual sphere we fortuitously had handy, and no dice.)

(Note the other way exists too: a projection can have a circle rendered on it, though it wouldn't be a circle on an actual sphere.)

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

#285

Post by anon84873628 »

necovek wrote: post #231
anon84873628 wrote: post #226

Earlier quoted context omitted.

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.

Sue can access the federated app through SSO.

The password reset flow, if offered by the SP at all, is only a fallback alternative to the SSO in case it becomes broken, and should only be used by organization administrators.

The inability to complete the MFA is what prevents the federated user data from being accessed in the case of a domain takeover, which is what we're discussing here. So you really want that to be implemented by the SP.

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

#286

Post by efrowning »

Pxtl wrote: post #269
efrowning wrote: post #221

Earlier quoted context omitted.

Sadly, this isn't fool-proof. Domains can go up for auction or backorder on a registrar, and they won't update the registration date if the domain is purchased this way since the registrar can consider this a transfer. It's a signal, for sure, but it will miss cases. It will also miss transfers sometimes, depending on the registrar.

I was trying to find cases of it happening historically so I could check the RDAP record to see how domain registrars use it in practice... and yeah, the registrars seem to ignore a lot of the spec. While they do generally seem to follow the "lapse and re-register = new registration date", I can see how your example is something they probably would break. RDAP records don't appear to show historical expirations and r…

Right? I wish this data was provided by the registrars! I want to know when a domain has lapsed to protect users with existing accounts from that domain on my services. RDAP is new enough that I'm hoping registrars start using it to spec, but I'm not holding my breath right now.

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

#287

Post by nodamage »

nodamage wrote: post #248
radlad wrote: post #156

Earlier quoted context omitted.

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…

Assuming the above is correct, if you decide to connect Google SSO to your application using option (3), then it is not a vulnerability that a Google account from a different workspace can connect to your application, because the entire point of option (3) is that users with any Google account (regardless of workspace) can connect to your application.

If you intended to restrict your application to users of your own workspace then you should have used option (1) or (2).

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

#288

Post by jimjonah »

It sounds like there’s a bug with the “sub” field. The author is stating that they can’t use it as a unique identifier for the user. Isn’t that the root of the problem?

A new domain owner could try to reuse email addresses, but since the domain is now in a new workspace the sub should be different and downstream services shouldn’t second guess that. Am I wrong about this?

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

#289

Post by moi2388 »

For the people not understanding the security risk, or how this would be something Google needs to solve, have a look at the claims of Microsoft Id token claims, and how their use of multiple guid claims completely eliminates this problem:

https://learn.microsoft.com/en-us/entra/identity-platform/id...

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

#290

Post by nodamage »

rahimnathwani wrote: post #147
nevir wrote: post #140

Earlier quoted context omitted.

By looking the account up with Google's People API - https://developers.google.com/people They would have to verify the account is active, AND the id hasn't changed

By looking the account up with Google's People API - https://developers.google.com/people They would have to verify the account is active If I log in using Google oauth, you already know the Google account is active. AND the id hasn't changed Yes, but that's an additional check, separate from the one you suggested would eliminate the issue: If, when you logged into Slack via Google Oauth with the email address user@c…

> If I log in using Google oauth, you already know the Google account is active.

You know there is an active Google account but (for the public OAuth integration option) it can be any Google account from any workspace, or no workspace.

"A public application allows access to users outside of your organization (@your-organization.com). Access can be from consumer accounts, like @gmail.com, or other organizations, like @partner-organization.com." [1]

> Yes, but that's an additional check, separate from the one you suggested would eliminate the issue:

If you set up an internal OAuth integration option no separate check is necessary, it will actually restrict access to users of your workspace.

"An internal application will only allow access to users from your organization (@your-organization.com)." [1]

You can use the SAML integration option as well. [2]

[1] https://support.google.com/cloud/answer/6158849?hl=en#zippy=...

[2] https://support.google.com/a/answer/6357481

Post reply on HN