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

121–130 of 297 posts

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

#121

Post by akovaski »

landryraccoon wrote: post #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!

Phone numbers too. Ah, but it's illegal to open mail addressed to someone else. (Although what if you change your legal name to match???!) Perhaps we need an electronic messaging service backed by the USPS.

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

#122

Post by nodamage »

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

I agree, I don't think this is a problem with Google's Oauth implementation, it's a problem with the service providers who authenticate users via the mere existence of an email address ending in @company.com without checking if the email address actually belongs to an active employee.

If, when you logged into Slack via Google Oauth with the email address user@company.com, Slack checked with company.com whether user@company.com was a valid user that should be allowed to login, then this problem would be avoided entirely because the defunct company would no longer report any valid users.

This would also avoid further problems with attackers being able to login with unattended email addresses like support@company.com, as was discussed here: https://news.ycombinator.com/item?id=41818459 (There's a lot of discussion below about whether the "sub" claim is stable or not but it's a red herring because of this IMO, also the proposed fix in the article wouldn't address it either.)

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

#123

Post by Pxtl »

niij wrote: post #100
Pxtl wrote: post #97

Earlier quoted context omitted.

I disagree. DNS stores enough information in WHOIS to see if ownership has changed, it's not DNS' fault that nobody looks. Probably the least-wrong thing to do with current DNS is to have authentication servers keep track of the WHOIS UpdatedDate of email domains. If a WHOIS UpdatedDate is newer than the corresponding user's linked email address verification, that user's email address is no longer trusted. Next time…

What does this protect against? If the WHOIS changes because someone new buys the domain then they could simply receive this reset emails, no?

Yes, but the user had to go through the process of "wait do I still have that email address? Did I receive it?"

Like, let's say I have an email address pxtl@example.net, and I used that to register an account on service.com, and example.net goes under.

In theory I know that this event has occurred, I no longer have access to my email address at pxtl@example.net.

So I log into my service.com account and get told "hey your email was pxtl@example.net - example.net has changed ownership. Is that still your email?" and I'll say "no" and put in a new email.

Or maybe I don't realize that example.net is gone. So I try to verify the account, find that I'm not receiving the email, and realize my mistake and set up a new email account, and click the button that says "I did not receive the email". The authentication server can prevent this window of time being an attack vector by forcing a delay between email validation and password reset, and by de-validating the email address (and treating it as a red flag on the whole domain) if the user clicks "I did not receive the email" a few minutes after the email address has been verified.

And if I forget my password and try to reset password on service.com using my unverified pxtl@example.net? "example.net had an ownership change since this email address was registered, please use another means to reset your password like SMS". Which is the main benefit of this process. Which I know doesn't require full verification.

Now, obviously the WHOIS updateddate is a noisy signal. Ideally the DNS system would expose a more granular ownership-change date - for example, gmail.com lists a WHOIS updateddate of July 11th 2024. UpdatedDate isn't supposed to change with every renewal but lots of things aren't supposed to happen.

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

#124

Post by OtherShrezzing »

simiones wrote: post #17
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,…

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.

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

#125

Post by patmcc »

danudey wrote: post #59
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,…

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…

>>>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?

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

#126

Post by citizenpaul »

It seems like there have been a number of security stories lately that essentially amount to. "no tech companies ever does cleanup" Which everyone on HN with a couple years or more experience should know is the norm. I expect a lot more of this to keep happening since companies will never really care about security without consequences ie a $10 fine for making $100 literally incentivies lack of security.

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

#127

Post by radlad »

nodamage wrote: post #122
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,…

I agree, I don't think this is a problem with Google's Oauth implementation, it's a problem with the service providers who authenticate users via the mere existence of an email address ending in @company.com without checking if the email address actually belongs to an active employee. If, when you logged into Slack via Google Oauth with the email address user@company.com, Slack checked with company.com whether user@c…

This is a misunderstanding of the problem. See my comment downthread: https://news.ycombinator.com/item?id=42701912

"hd" is Google's solution to this problem, and "hd" is also the source of this vulnerability.

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

#128

Post by rahimnathwani »

nodamage wrote: post #122
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,…

I agree, I don't think this is a problem with Google's Oauth implementation, it's a problem with the service providers who authenticate users via the mere existence of an email address ending in @company.com without checking if the email address actually belongs to an active employee. If, when you logged into Slack via Google Oauth with the email address user@company.com, Slack checked with company.com whether user@c…

  If, when you logged into Slack via Google Oauth with the email address user@company.com, Slack checked with company.com
How would they check that?

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

#129

Post by [deleted] »

Pxtl wrote: post #97
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…

I disagree. DNS stores enough information in WHOIS to see if ownership has changed, it's not DNS' fault that nobody looks. Probably the least-wrong thing to do with current DNS is to have authentication servers keep track of the WHOIS UpdatedDate of email domains. If a WHOIS UpdatedDate is newer than the corresponding user's linked email address verification, that user's email address is no longer trusted. Next time…

[deleted]

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

#130

Post by freedomben »

codetrotter wrote: post #81
danudey wrote: post #67

Earlier quoted context omitted.

"The f___ing article"

In polite terms it can also mean “the featured article”. And IMO it makes more sense to read it that way in a top-level comment. Whereas reading it as the f’ing article makes more sense when the word “TFA” is used in a response to another comment like “well, you say that but TFA said such and such”.

Agreed. I've also seen "The Fine Article"
Post reply on HN