Live data from Hacker News

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

trufflesecurity.com

111–120 of 297 posts

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

#111

Earlier quoted context omitted.

If a security mechanism doesn’t account for failure cases, it’s a failure of the security mechanism. It’s a hard problem to solve and I don’t have a solution, but it’s a core goal of every security tool to account for edge cases and failure cases like this. If you tell me that OAuth is completely insecure due to a security issue, it’s not going to make me feel any better if you say “but it’s totally not OAuths fault”…

So you use email/pass and the reset password email dumps right to the new party as well, because they control the MX records for the domain?

That's why allowing account recovery using (exclusively) email is indeed a security problem.

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

#112

Earlier quoted context omitted.

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

> Magic links and password resets are all going to give the new owner access.

Which is why you should never exclusively rely on either for sensitive services.

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

#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 OAuth, or any OAuth at all.

Nothing in that write-up makes sense.

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

#114
If you think this is bad, wait until you move physical addresses and don’t notify all your creditors!

Literally ANYONE who moves into your old house will have access to your bank statements, credit card bills, tax forms, auto registration and who knows what else. And it will all come plaintext and unencrypted!

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

#115

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

What if DankStartup doesn't fold and just forgot to renew their domain, or lost control of their domain for some reason. OAuth shouldn't let you Auth someone else's account just because you can hijack their domain.

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

#116
Nearly a decade ago, there was a website called thehunt.com that basically ran out of money and some employees were acqui-hired by pinterest.

All of the assets were left to rot and at the time the company was a good match for another startup of mine. So I reached out to the investors I found on crunchbase and asked if I could acquire everything. We worked out a deal and I did. The issue was the complete lack of people from the old company willing to assist and the complete lack of data for alot of things. There was 1 or 2 people who we could ping from the old company to ping who were super helpful, but the big thing was many things were just lost to time- passwords, history, code repos, etc..

Simply creating a new google apps account allowed us to get full access back to everything - We could even read old slack messages (even DMs!) by resetting each accounts password. The whole thing was shocking to say the least, but with that access we got back into literally every service they used and managed to get it up and running again within a week, which was a good thing because nearly every service it was using was threatening to shut it down every day for lack of payment.

I think the solution here is actually way simpler than most make it out to be and could easily be a startup for someone:

Create a startup that lets customers simply enter in domains. If the domain EVER goes into the "pendingDelete" status, inform the customer. The customer would be random SAAS's that want to protect against this type of attack and could simply choose to disallow access to any account that has had their domain go into that status.

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

#117

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

Besides the github account with a legitimate name, but impostor ownership, I can imagine another case which is problematic. HR SaaS companies might be required by law to maintain the account for a period of time - let's say until the end of the next fiscal year. The account still existing is not a failure on either Google, the SaaS company or DankStartup. The problem, as other posters mentioned is the fact the new account has the same ID in OIDC as the previous one, which is what the author of TFA proposes.

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

#118

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

I don't think it would be 100% on the failed startup considering most of, if not all, of the applications mentioned likely do not actually delete accounts even when you say to delete them. There probably could be some allowance made for the situation but also you're repurposing the domain of a failed startup.

I don't think the problem was necessarily with Google though as I believe they create a unique ID for the domain. The problem with be with the other services like ChatGPT, Slack, etc that associate with the domain and create accounts for each user in the domain.

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

#119

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.

> Just don't tell the web 3.0 folks cause I don't necessarily mean a blockchain.

Isn't this literally what certificate chains are for? Establishing a chain or custody - or rather, a chain of liability?

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

#120
post #93

Earlier quoted context omitted.

But authors does imply that sub will also change in place for users in step #1, without the workspace beeing recreated. And as such the sub is not usable as a general identifier for the user resource differentiation.

The sub property appearing to change for the same email address is a valid scenario. SPs failing to respect that scenario because they don't understand it, or because it's not what some of their users want, is not a valid excuse. https://support.google.com/a/answer/33314?hl=en&co=DASHER._F... To me it is reasonable that orgs may want to eventually reuse an email address on a different user account. That's a feature d…

> To me it is reasonable that orgs may want to eventually reuse an email address on a different user account. That's a feature decision made by the IdP so SPs need to respect it

I think everyone, including the authors hopefully agrees with that logic and sentiment. And that would be the literal point of the sub claim after all!

But the implication in the article is still, as i read it, that it changes in place in practice, and not in the case of re-creating the user under the same workspace. But i obviously do not have the background to clarify!

Post reply on HN