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

221–230 of 297 posts

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

#221

Post by efrowning »

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

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.

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

#222

Post by efrowning »

saguntum wrote: post #72
banger180 wrote: post #25

> “The sub claim changes in about 0.04% of logins from Log in with Google. For us, that's hundreds of users last week”. What I don't understand is why the `sub` claim is not consistent for those users at Google. To my understanding of the OIDC protocol the `sub` should be unique for a specific user. Additionally as far as I understand if you take over a defunct domain and create a new google workspace with new users…

That sub identifier changing without the underlying user changing may be the core of the bug. It's not fully clear from the post IMO. I posted a little breakdown here: https://news.ycombinator.com/item?id=42701030 I don't think the article clearly states one way or another whether those 0.04% of sub claims changing are legitimate end user changes or not. If those sub changes are legitimately the Google Account changi…

How would the clients tell if the account has a valid sub change or not if the only piece of information provided is that the sub claim changes? For this particular attack, without having some kind of Google Workspace account identifier for the domain, the sub claim doesn't sound sufficient to validate that it's the same Google account from the client's side. I'm guessing the engineer at the major tech company didn't provide that stat without checking if those users were valid, active accounts.

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

#223

Post by efrowning »

tom1337 wrote: post #16

Is this really an issue? Back when I implemented Google OAuth I used the "sub" that Google gave me as well as the email. I'd wager that Google does not re-use a sub for the same E-Mail so if the account is deleted and then somebody grabs the domain and re-created the account they'd have the same E-Mail but a different sub which would make the login fail. Seems to not be an issue in Google's OAuth Flow but rather the…

Are your users primarily using gmail accounts or are they using accounts from custom domains? TFA does't say exactly, but I wonder if this stat only applies to users with custom domains rather than @gmail accounts.

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

#224

Post by fastest963 »

We take the OAuth2 token and make a call to the People API [0] to get the Person resourceName. Not sure if this is more stable than "sub" but we completely ignore that.

[0] https://developers.google.com/people/api/rest/v1/people/get

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

#225

Post by delfinom »

radlad wrote: post #109
stackghost wrote: post #96

Earlier quoted context omitted.

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

Yea "hd" doesn't work here.

Users can make google accounts with corporate domains but without gsuite hosting attached. The same concern applies to just @gmail.com addys. Google has gotten big on nuking inactive accounts now, what stops similar openings where a person's inactive account gets recreated by an attacker and waltz his way into SSO systems? There's some corporate systems (usually benefits) that allow personal emails attached to the same account as work emails for example.

I imagine the fact the author is writing that Google reopened the bug and is issuing a bounty means there are Google engineers more than aware of the issue rather than trying to argue what Google does and does not intend.

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

#226

Post by anon84873628 »

jpc0 wrote: post #157
anon84873628 wrote: post #108

Earlier quoted context omitted.

Those password resets should have some sort of MFA step.

Sue lost hee phone, she used KeePass for everything and didn't back it up. She get some support from IT, what do they do to solve Sue's problem? They reset her password and 2FA and have her redo them. She probably gets a lecture about backups or she spurns a brand new company policy that "Everyone should now use LastPass and nothing else is supported". If they as administrators cannot do that, Sue has now lost signif…

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.

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

#227

Post by ocdtrekkie »

rahkiin wrote: post #107
mtkd wrote: post #92

Earlier quoted context omitted.

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

What happens when your service provider that owns your domain collapses?

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

#228

Post by verdverm »

ycombinatrix wrote: post #178
verdverm wrote: post #78

Earlier quoted context omitted.

Web 3 already tried this, it was called Handshake. I think their downfall is they wanted to replace ICANN / DNS rather than work with and alongside the current system.

shame, ICANN sucks

I would argue the crypto bros are worse

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

#229

Post by YetAnotherNick »

lxgr wrote: post #112
horsawlarway wrote: post #105

Earlier quoted context omitted.

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.

It's better than SMS based password recovery or "call support to reset your password". What do you suggest is the best approach.

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

#230

Post by deathanatos »

> 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 attention to quality, or rather, lack thereof, could cash those outlandish claims.

There is a simple explanation here: Your staff SWE is wrong. `sub` is the claim you're looking for.

Extraordinary claims require at least a trifling of proof. Or, what can be asserted without evidence can also be dismissed without evidence.

And this alleges to be a security blog. As a writer with that target audience, you should know this is going to be the objection to the thesis that your reader will have, and you attempt to just handwave it away…?

Post reply on HN