what a shitty headline and opening paragraph.
anyway, if you use SSO on a domain and then let the domain drop, you're an idiot and there will be bad consequences for your data.
Google’s OAuth login doesn’t protect against purchasing a failed startup domain
31–40 of 297 posts
Re: Google’s OAuth login doesn’t protect against purchasing a failed startup domain
#32> They also classified the issue as a “Fraud and abuse” issue, rather than an Oauth/login issue. I can _kinda_ see that, I agree they should mitigate it as best as possible too though, especially since they're Google after all. > I thought this would be the end of the story, but 3 months later, they re-opened my ticket (after my Shmoocon talk was accepted), paid a $1337 bounty, and said they were working on a fix. Sa…
$1337 is a very curious amount. Surely, someone was being clever???
yeah, google likes to have fun with the Bug Bounty program. See: https://bughunters.google.com/about/rules/google-friends/662...
Re: Google’s OAuth login doesn’t protect against purchasing a failed startup domain
#33[deleted]
Re: Google’s OAuth login doesn’t protect against purchasing a failed startup domain
#34> They also classified the issue as a “Fraud and abuse” issue, rather than an Oauth/login issue. I can _kinda_ see that, I agree they should mitigate it as best as possible too though, especially since they're Google after all. > I thought this would be the end of the story, but 3 months later, they re-opened my ticket (after my Shmoocon talk was accepted), paid a $1337 bounty, and said they were working on a fix. Sa…
$1337 is a very curious amount. Surely, someone was being clever???
It's leetspeak
It spells "leet" - see https://en.wikipedia.org/wiki/Leet
You're too young to have used BBSes :)
Re: Google’s OAuth login doesn’t protect against purchasing a failed startup domain
#35It'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,…
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…
[deleted]
Re: Google’s OAuth login doesn’t protect against purchasing a failed startup domain
#36It'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,…
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.
Re: Google’s OAuth login doesn’t protect against purchasing a failed startup domain
#37Thankfully, apparently this only affects Americans.
Re: Google’s OAuth login doesn’t protect against purchasing a failed startup domain
#38> “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…
I agree, in my limited experience the sub remains consistent even when changing the Google Workspace domain. So the email changes but sub remains the same. The issue seems to be clients matching on email/hd claim instead.
I wonder what action is causing the sub to change like the author suggests is happening.
Re: Google’s OAuth login doesn’t protect against purchasing a failed startup domain
#39It'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,…
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.
Re: Google’s OAuth login doesn’t protect against purchasing a failed startup domain
#40I 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 IT error that lead to a reprovisioning of the user, etc.
I also fail to see how the proposed solution of having a 'A unique user ID that doesn’t change over time' is different from the `sub` claim. However, the new ID associated to the domain could make sense to enforce a strong 'Everyone from the @domain.com has access' statement.
[1] https://developers.google.com/identity/gsi/web/reference/js-...