Google’s OAuth login doesn’t protect against purchasing a failed startup domain • Hacker News Board

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

#101

Post by throw0101c » Tue, Jan 14, 2025, 6:40 PM UTC

In iSCSI, there are a few options for addressing the block storage devices, with one being the iSCSI Qualified Name (IQN) that uses the domain name. But it includes a timestamp:

      -  A date code, in yyyy-mm format.  This date MUST be a date
         during which the naming authority owned the domain name used in
         this format, and SHOULD be the first month in which the domain
         name was owned by this naming authority at 00:01 GMT of the
         first day of the month.  This date code uses the Gregorian
         calendar.  All four digits in the year must be present.  Both
         digits of the month must be present, with January == "01" and
         December == "12".  The dash must be included.

* https://datatracker.ietf.org/doc/html/rfc3720#section-3.2.6....

* https://en.wikipedia.org/wiki/ISCSI#Addressing

       iqn.2001-04.com.example.storage:tape.sys1.xyz

       iqn.2000-02.edu.example.cs:users.oaks:proto.target4

* https://datatracker.ietf.org/doc/html/rfc3721

Clever idea to note change of ownership situations.

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

#102

Post by dylan604 » Tue, Jan 14, 2025, 6:41 PM UTC

chasemiller wrote: post #32

dylan604 wrote: post #12

Earlier quoted context omitted.

$1337 is a very curious amount. Surely, someone was being clever???

yeah, google likes to have fun with the Bug Bounty program. See: https://bughunters.google.com/about/rules/google-friends/662...

it's funny that all of the soul has not been sucked out of the entire company

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

#103

Post by ajross » Tue, Jan 14, 2025, 6:42 PM UTC

nijave wrote: post #50

simiones wrote: post #23

Earlier quoted context omitted.

> Basically if Sally, the CTO of DankStartup, signed up for Taskrabbit or whatnot, it's possible for you as the owner of the domain to impersonate Sally in the context of that relationship. I don't think this is the issue, unless someone went to some pretty extreme lengths. Configuring OAuth such that the company Google Workspaces account is recognized by Taskrabbit as a valid SSO option is not as simple as signing u…

Even then (in my experience) it's pretty common to setup an email based account and it will auto link to an oauth one that already exists. Even if Google revoked oauth, many platforms let you use the email directly to login

Yes, but that's not a bug with Google OAuth. If Taskrabbit (in the example) decides to trust dankstartup.com emails as a root of trust for identity even though the business failed, that's on them[1], and certainly nothing Google can have prevented.

The contention in the article is that dankstartup.com's new owners can leverage their control of the domain to get access to existing OAuth-based sessions that will look to the service providers as if Google has authenticated the account holder.

[1] And just to repeat: that risk is precisely why serious businesses (Vanguard in the example) don't allow obscure email domains as authentication anymore.

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

#104

Post by Ronnie76er » Tue, Jan 14, 2025, 6:44 PM UTC

As others have noted, this feels like an issue in the relying parties not relying on the `sub` field to validate the user. It feels the exact same as this issue here: https://bhavukjain.com/blog/2020/05/30/zeroday-signin-with-a....

In both, the details around the `sub` field, the field that should actually be used to identify the user, is poorly described. I would say that both of these feel a bit sensationalist, but then again, if relying parties are NOT using the sub field to validate users, they should be called out.

It seems to be that a good way to make some money is find every such situation where RPs are not using sub, and submit vuln bugs.

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

#105

Post by horsawlarway » Tue, Jan 14, 2025, 6:44 PM UTC

YetAnotherNick wrote: post #39

stackghost wrote: post #7

It's not 100% clear to me, from reading TFA, what the actual vuln is. Suppose DankStartup folds and I, being a morally-dubious sort of fellow, purchase dankstartup.net which I then use to sign into DankStartup's O365, or DankStartup's ChatGPT as a DankStartup employee. Isn't that a failure on DankStartup's part, to not shut down their business accounts? And isn't it also a failure on e.g. Microsoft or OpenAI's parts,…

And not only that, almost every form of auth has the same vulnerability not just log in with Google. If you own the domain, you own the email IDs as well and you can very likely reset password.

Yeah, this is the part I'm struggling with. This is absolutely not unique to google oauth, it genuinely seems like a misunderstanding of how the web manages trust.

If you own the domain, you own all the property associated with the domain, including all the old email addresses. Magic links and password resets are all going to give the new owner access.

Your best bet as a solution is to be using strict 2fa (ex - a yubikey might help here) but even that is likely just "a conversation with support" away from being circumvented.

This is why winding down a company is supposed to have specific stages and policies associated with the dissolution. You don't just abandon the offices and leave all the filing cabinets behind either, for similar reasons...

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

#106

Post by anon84873628 » Tue, Jan 14, 2025, 6:45 PM UTC

scarface_74 wrote: post #84

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.

There are some 3rd party accounts that can be accessed via your SSO or via your personal credentials once you leave. The main ones I can think of is your brokerage account containing your 401K and vested RSUs and your payroll provider like ADP and Paylocity. You still need to have access to past paystubs and end of year tax documents.

SSO should stop working when the IdP org is disabled/deleted. IdPs should not allow the org to be resurrected based solely on domain ownership alone. And if a new org is created with the same domain, the SP will need to be reconfigured with new OAuth client creds, and should be relying only on the `sub` claim anyway.

Any accounts you need after leaving a company should be tied to your personal email.

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

#107

Post by rahkiin » Tue, Jan 14, 2025, 6:45 PM UTC

mtkd wrote: post #92

rahkiin wrote: post #75

Earlier quoted context omitted.

Any domain takeover allows email takeover which allows you to send password reset emails for former employees. Does not matter if it is with oauth or not

And many vendors will send "restart your service today for $x" for months afterwards so data not deleted Some SaaS ecommerce platforms and email marketing services will likely give a restarted domain entire customer databases ...

There should be some service for permanently destroying a domain with a single prepaid cost. Somehow preventing bankruptcy laws from getting the domain.

Pay X$ up front, then Y$ per month to keep active. Once you cannot pay, it gets blocked forever (paid for by the up front cost). Owned by your service provider so not part of your firesale

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

#108

Post by anon84873628 » Tue, Jan 14, 2025, 6:46 PM UTC

rahkiin wrote: post #75

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…

Any domain takeover allows email takeover which allows you to send password reset emails for former employees. Does not matter if it is with oauth or not

Those password resets should have some sort of MFA step.

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

#109

Post by radlad » Tue, Jan 14, 2025, 6:49 PM UTC

stackghost wrote: post #96

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…

>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 and internal applications" here: https://support.google.com/cloud/answer/6158849?hl=en#zippy=...

Some applications (e.g. Tailscale) take advantage of the public Google OAuth API to provide private internal corporate accounts. A common misconfiguration here is to use the domain portion of the "email" attribute - this can be spoofed by Google Workspace admins. That's not what's happening here.

Instead, 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. This field cannot be overridden by Google Workspace admins. The trust breaks down when the domain changes hands, a new Google Workspace account is opened, but the old "hd" value is reused.

You can read more about "hd" here: https://developers.google.com/identity/openid-connect/openid... (find the table and read the descriptions for both "email" and "hd".)

You can avoid this issue by using a custom Google OIDC IdP configured for internal access only in your applications, rather than using a pre-configured public Google OIDC IdP (be very careful you mark it internal!) A new domain owner would not be able to retrieve the secret key you previously generated.

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

#110

Post by scarface_74 » Tue, Jan 14, 2025, 6:50 PM UTC

anon84873628 wrote: post #106

scarface_74 wrote: post #84

Earlier quoted context omitted.

There are some 3rd party accounts that can be accessed via your SSO or via your personal credentials once you leave. The main ones I can think of is your brokerage account containing your 401K and vested RSUs and your payroll provider like ADP and Paylocity. You still need to have access to past paystubs and end of year tax documents.

SSO should stop working when the IdP org is disabled/deleted. IdPs should not allow the org to be resurrected based solely on domain ownership alone. And if a new org is created with the same domain, the SP will need to be reconfigured with new OAuth client creds, and should be relying only on the `sub` claim anyway. Any accounts you need after leaving a company should be tied to your personal email.

My brokerage account could be accessed by both. I agree that is how it should work. But my brokerage account provider is never told to disable access via my IdP. It’s up to my former IdP to not do something stupid like giving someone else my old email address.