81–90 of 297 posts
Earlier quoted context omitted.
whats is TFA ?
"The f___ing article"
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”.
I'm not sure I agree that it's a flaw in Google's OAuth implementation. Domain ownership is the source of truth for many systems and, as the article alludes to, expired domains can be abused in a variety of ways.
> To resolve this issue, Google could implement two immutable identifiers within > its OpenID Connect (OIDC) claims: > 1. A unique user ID that doesn’t change over time. > 2. A unique workspace ID tied to the domain. 1. is the OIDC `sub` claim! I strongly suspect that in those 0.04% of accounts where the anonymous quoted engineer reports that the `sub` claim changed, what actually happened was some provisioning/onboa…
If services are not respecting the `sub` claim in this case, then they are giving the new Google account access to the old account's data. Companies probably wouldn't complain about this because they think it is the expected/reasonable behavior. Also it's likely that in many scenarios it is the same human behind the different accounts, e.g. if they leave a company then return.
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…
Yes but he's saying the data on 3rd-party websites should be deleted by the failed startup when they shutdown not just left to sit there.
Earlier quoted context omitted.
Third parties is google as single sign on. If such an org/domain is abandoned, a malicious person could 'resurrect' the accounts on those third party sites. It's kind of like a similar situation where a user deletes an email account and then someone else creates an new one in its place, and now they have access to all the third party password reset links. Except in the case linked above, the user never had the abilit…
In emails case all the larger providers I'm aware of retire addresses to prevent this sort of abuse, probably learned the hard way. Could Google OAuth do something similar here? It now occurs to me that large businesses might have the same issue with emails and former employees (easy to imagine John Smith departing and at a later date John Smith being hired) so I wonder how they typically handle this.
I know when interns were at Amazon and left, their accounts were disabled. But when they came back, they got their old accounts back and the related Slack users
I have worked with a few of these downstream providers to look for a solution. There is a documented unique user identifier (the sub claim) that could theoretically prevent this issue, but in practice, it's unreliable ... 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. For us, that's hundreds of users last week”.
The real solution is to use the sub claim, and not hd/email. If sub is unreliable, let's fix that. That said, I'm surprised sub is documented as unreliable here; I wonder if there is perhaps something else going on. I've done a lot of work with oauth and I haven't found sub to be so mutable, but then again, who knows maybe I just missed it?
And yeah, lapsed domains => domain takeover => email takeover and impersonation will always be a baseline problem, independent of oauth.
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…
That is not quite true, the sub field will be different.
Earlier quoted context omitted.
>Expecting an entity that has already failed* to not fail again isn’t an effective security control, unfortunately. Sure, I'm sympathetic to that, but again I don't see how that's within the scope of oauth.
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…
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 domain are under the control of a new party. For all Google knows, you did this entirely above board and in a coordinated fashion.
That new party controls the property. Email resets will also dump right into their hands (They control the MX records for corpdomain.com now...).
Legally speaking, it's not even clear you're right - the new person might well be the person actually entitled and expressly supposed to be accessing that service as that account (if the domain was sold as part of an acquisition or sale).