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

151–160 of 297 posts

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

#151

Post by chavesn »

cortesoft wrote: post #141
nodamage wrote: post #134

Earlier quoted context omitted.

I'm not talking about checking against the domain, but checking against a directory of active users.

Where does this “directory of active users” exist? If it is controlled by slack, then you are relying on a failed startup to properly notify ALL the 3rd parties when they shut down. Failed startups don’t always shut down cleanly like that.

> Failed startups don’t always shut down cleanly like that.

Agreed, and with the number of services and the "ease" of oauth it's likely impossible to even track. You could make a list of the major ones, but there could be hundreds per user, ultimately thousands of unique services used depending on the breadth of the startup's activities.

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

#152

Post by chavesn »

If oauth makes an authenticity claim, it should be true. Saying it's the same user when it's not is bad, clearly.

in other words: Google could make a more accurate authenticity claim than they currently do.

This problem would be worse without oauth, though, right? With plain email login, all they would need to do is "forgot password" and there wouldn't even be a way to tell.

in other words: Email login would never be able to make a more accurate authenticity claim.

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

#153

Post by chavesn »

herczegzsolt wrote: post #70
loginatnine wrote: post #52

Earlier quoted context omitted.

I've been working with an app that uses Google to login for the past 10 years, and I've had problems with sub changing when these situations happened : - Domain change - Company being bought by another one and being integrated in their Google Workspace - Employee leaving and coming back To us, it's very very far from the quoted 0.04% which is to me very high. I had to deal with it 5-6 times in the past 10 years but o…

In my opponion, all of those cases very well justify a manual check, or some sort of extended identification before the user is let in. It indicates a deeper cultural issue of "convenience/profit over security" if those are sufficient reasons to not check the sub parameter.

> all of those cases very well justify a manual check, or some sort of extended identification before the user is let in.

Just curious, what would that check look like that's not open to the same vuln?

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

#154

Post by chavesn »

loginatnine wrote: post #40

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…

Genuine question, what would that flow look like?

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

#155

Post by radlad »

nodamage wrote: post #143
radlad wrote: post #138

Earlier quoted context omitted.

That's what an identity provider (e.g. AD, OneLogin, Okta, Duo SSO, Google OAuth, etc.) is supposed to be, ostensibly.

Yes. If you've set up your Slack so each login checks against the identity provider to ensure an active user is logging in, that would resolve the issue, no? Even if you take over company.com's domain you can't reconfigure company.com's Slack to point to a new identity provider?

I think you may be a bit confused about the players here. When you use Google OAuth to login, it _is_ your identity provider, and it is reporting to Slack that the user exists. Google is reporting the user exists because it exists in the Google Workspace directory. You use this as your source of truth for provisioning users, and they automatically get access to all of your company's apps.

The problem is that even though the user has the same email (joe@example.com), and the same Google Workspace domain ("hd": example.com), this is actually a _new_ Google Workspace account. But nothing Google provides to Slack allows them to detect this.

Slack, et al can fix this by _not_ using the public Google OAuth integration, and forcing every use to configure an individual internal Google OAuth integration. But they use the public one because Google has said it is a safe and secure way to operate their service.

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

#156

Post by radlad »

nodamage wrote: post #150
radlad wrote: post #127

Earlier quoted context omitted.

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.

I don't think so, but please go ahead and clarify if that is the case.

Maybe you can clarify what part of the linked comment didn't make sense? It's a bit hard to make out where the confusion is if the above comment didn't help clarify.

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

#157

Post by jpc0 »

anon84873628 wrote: post #108
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

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 significant business data, there will be a dexent amount of work stopped to get Sue onboarded again and this is a significant issue.

An auditable log that X reset Sue's password ane 2FA codes at x time while at x location with biometric authentication is pretty secure. If X also ca nnot touch those logs the next strawman falls apart.

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

#158

Post by lysace »

bitpush wrote: post #145
paxys wrote: post #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…

The staying power of a Google = bad article on HN top page is insane.

And the opposite: The half-life of an Apple = bad article on HN is insane in the other direction.

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

#159

Post by radlad »

rahimnathwani wrote: post #147
nevir wrote: post #140

Earlier quoted context omitted.

By looking the account up with Google's People API - https://developers.google.com/people They would have to verify the account is active, AND the id hasn't changed

By looking the account up with Google's People API - https://developers.google.com/people They would have to verify the account is active If I log in using Google oauth, you already know the Google account is active. AND the id hasn't changed Yes, but that's an additional check, separate from the one you suggested would eliminate the issue: If, when you logged into Slack via Google Oauth with the email address user@c…

Right, this additional check should not be necessary in a typical OAuth or OIDC flow. This workaround is only necessary in this case because the API Google offers to services has a hole in it.

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

#160

Post by radlad »

okdood64 wrote: post #144
rahimnathwani wrote: post #128

Earlier quoted context omitted.

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?

Either slack or some other third party provider could have a whitelist maintained by IT? Just spitballing.

It is certainly an option to pre-provision accounts in your application (e.g. Slack) and then have any users authenticating from the SSO product compared against the list of authorized users. And for some products which sell licenses by seat, this is exactly what they do.

But for many products which are meant to be available to an entire organization, this is a big part of what SSO was supposed to solve in the first place: IT no longer has to provision (and de-provision) user accounts in every single application. Maintaining an allowlist in each application makes this pointless.

Post reply on HN