Live data from Hacker News

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

trufflesecurity.com

211–220 of 297 posts

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

#211
post #89
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…

> They are (or were) refusing to provide any indication to those other companies that these are not, in fact, the same people That is not quite true, the sub field will be different.

If by "same people" you mean recognizing a specific user, yes the sub field changes.

If by "same people" you mean being able to tell whether a new user is part of the same organization, the sub field is useless and no other field has this information either.

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

#212

I really don't understand here, the proper way to use Google's OpenID implementation to authenticate someone is to use the `sub` claim. Don't use the email, don't verify it yourself, use the `sub` claim. It's a known fact and is properly documented[1]. If the `sub` changes, it's because it's not necessarily the same person so have a flow ready for that. It could be an employee left and came back, a domain change, an…

I've implemented OAuth flow glue logic a bunch in my career and I agree that the logic doesn't seem to follow from what the documentation says. What's not clear to me though while reading this is, if I delete/lose a domain, and someone re-makes the domain and account with the same email address, does the sub value then change? The docs would seem to suggest yes, but then I am not clear what google actually ended up "…

The reason this is an issue is that the sub value changes often enough that intergrations ignore it rather than bother users with having to re-OAuth.

As far as what Google is doing in the bug bounty, that's a good question -- we don't know. The author is proposing two new values, for the domain and user, that wouldn't change in the cases that sub changes now, but would change in this case.

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

#213

Earlier quoted context omitted.

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"

This is the old school “polite” version, as in, “read the fine manual”

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

#214
post #125

Earlier quoted context omitted.

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

It's a different bob@DankStartup.com, and in fact a completely different DankStartup.com. Google shouldn't conflate the two. There are exactly 0 situations where the current behavior is useful. There is no reason whatsoever to have the exact same auth info for two Google accounts that happen to have the same domain.

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.

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

#215

I really don't understand here, the proper way to use Google's OpenID implementation to authenticate someone is to use the `sub` claim. Don't use the email, don't verify it yourself, use the `sub` claim. It's a known fact and is properly documented[1]. If the `sub` changes, it's because it's not necessarily the same person so have a flow ready for that. It could be an employee left and came back, a domain change, an…

Yeah, I'm not really clear on the vuln. It sounds like clients don't validate sub claims because they are unstable? Google's docs say they should. When I first read the post, I thought that maybe Google was reusing sub claims when they shouldn't, but on a closer read, maybe it's the opposite problem - that the sub claim is changing when it should not change? From the article - “The sub claim changes in about 0.04% of…

I ran into this when implementing OIDC at work. One of my teammates wasn't able to login even though he just linked his google account. Turns out based on which browser session he was using, the same google login was giving a different sub. Super weird behaviour.

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

#216

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.

You don't need a whole chain of custody, you just need to know that the current owner is the one you care about. TXT DNS records or magic URLs can do the trick.

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

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

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

#218

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…

It seems to be at the registry level. But registries do show changes in owner [implicitly at least].

Maybe there needs to be a way to do some signalling/lookup when domains changes hands.

Sounds like a job for a blockchain, lol.

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

#219

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

It's similar to Gmail or Hotmail or Yahoo Mail hypothetically allowing a new user to adopt an abandoned email address. Most email services don't allow this for this very reason.

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

#220
post #208

Okay, this made me curious if there was a technical solution to this that people could be providing using the existing tools available, and I think there is. RDAP and WHOIS will return the creation date of a domain. These fields are controlled by the registrar not the registrant. That creation/registration date gets reset when the domain is lapsed and picked up by somebody new. So, when doing any domain-name-based au…

[deleted]
Post reply on HN