141–150 of 297 posts
Earlier quoted context omitted.
If the attacker is in control of company.com, checking against this domain would not help.
I'm not talking about checking against the domain, but checking against a directory of active users.
Earlier quoted context omitted.
I register a Google Workspace and add CorpDomain.com to it. I then use that to OAuth to other companies (e.g. Slack, payroll companies, etc.). Then my company goes under or closes up and the domain lapses. Someone else comes along, registers a completely different Google Workspace but attaches that same domain to it. The e-mail address is the same, but it's obviously a new Google Workspace with new people, new paymen…
I'm not entirely clear on what you expect in this case? You're registering with those 3rd parties using a property (the email address under corpdomain.com) that is now owned by the new party. This feels a lot like complaining that you hired a lawn service and told them to mow at your address, and then didn't update the address or cancel service after you moved. You've sold the domain. Assets associated with the domai…
Not parent-poster, but from what I can piece together it sounds like the distinction between Google attesting that:
1. This is the person who currently controls the same e-mail address.
2. The is the person who currently controls a sub-account of the same Google Workspace which was in the past identified by this e-mail address.
> You've sold the domain. Assets associated with the domain are under the control of a new party.
True, but that "control" does not (and should not) automatically mean legal ownership of every kind of internet account that was ever made with that e-mail address.
While the prior-controller has a degree of responsibility, so does Google when it knows that ownership of those other facets were not transferred.
> This feels a lot like complaining that you hired a lawn service and told them to mow at your address, and then didn't update the address or cancel service after you moved.
I feel the analogy need at least three kinds of party: The old/new home owners, the lawn-cutting service, and a marketplace or middleman which is failing to pass along the change in ownership.
Earlier quoted context omitted.
I'm not talking about checking against the domain, but checking against a directory of active users.
That's what an identity provider (e.g. AD, OneLogin, Okta, Duo SSO, Google OAuth, etc.) is supposed to be, ostensibly.
Even if you take over company.com's domain you can't reconfigure company.com's Slack to point to a new identity provider?
Earlier quoted context omitted.
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?
Just spitballing.
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…
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…
>>>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?
What is my remedy?
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?
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
AND the id hasn't changed
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.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…
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…
Earlier quoted context omitted.
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.