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,…
My father changed careers and dissolved his business over a decade ago, at which point he let his old domain lapse. A couple years ago, I began to wonder if anyone was still trying to reach him, so I bought the domain (domain squatters weren't even interested in it anymore) and setup an inbox for his old email address. In less than a week, the unread count was in the triple digits. It was basically all marketing and…
Google’s OAuth login doesn’t protect against purchasing a failed startup domain
191–200 of 297 posts
Re: Google’s OAuth login doesn’t protect against purchasing a failed startup domain
#192This is more of a fundamental issue with the way we rely on DNS to secure *gestures wildly* all the things. The fact that domains can expire and be registered by someone new allows the new owner to do almost anything the old owner could have done when it comes to anything trusting email addresses, or anything else relying on DNS (ACME certs) for authentication. It's great for "do they own this right now" validation a…
I disagree. DNS stores enough information in WHOIS to see if ownership has changed, it's not DNS' fault that nobody looks. Probably the least-wrong thing to do with current DNS is to have authentication servers keep track of the WHOIS UpdatedDate of email domains. If a WHOIS UpdatedDate is newer than the corresponding user's linked email address verification, that user's email address is no longer trusted. Next time…
Maybe registrars could set a unique ID per registrant, and if a domain expires and is purchased by a different entity/account than the previous one the registrant GUID is refreshed. That could then be a signal that all previous reliance on the DNS of the domain name should be null and void
Re: Google’s OAuth login doesn’t protect against purchasing a failed startup domain
#193Earlier quoted context omitted.
What does this protect against? If the WHOIS changes because someone new buys the domain then they could simply receive this reset emails, no?
Yes, but the user had to go through the process of "wait do I still have that email address? Did I receive it?" Like, let's say I have an email address pxtl@example.net, and I used that to register an account on service.com, and example.net goes under. In theory I know that this event has occurred, I no longer have access to my email address at pxtl@example.net. So I log into my service.com account and get told "hey…
WHOIS has been superceded by RDAP, and RDAP provides event data for registration and re-registration. So even better!
edit: it doesn't seem like registrars actually do re-registration, and many cctlds don't even use RDAP yet.
Re: Google’s OAuth login doesn’t protect against purchasing a failed startup domain
#194Earlier quoted context omitted.
Part of my company dissolution process is to renew the domain name for 10 years to prevent exactly this
Is the hope that this sort of attack is just less useful in 10 years? What happens after 10 years?
Re: Google’s OAuth login doesn’t protect against purchasing a failed startup domain
#195Earlier quoted context omitted.
My father changed careers and dissolved his business over a decade ago, at which point he let his old domain lapse. A couple years ago, I began to wonder if anyone was still trying to reach him, so I bought the domain (domain squatters weren't even interested in it anymore) and setup an inbox for his old email address. In less than a week, the unread count was in the triple digits. It was basically all marketing and…
This is very much a critical flaw in systems which rely entirely on email or domain names as the sole security factor. OAuth itself is flawed in that it allows this terrible practice, though to be fair it does discourage it. Google's specific OAuth solution encourages this compromised practice even more, because the only identifier it provides for a user group is the domain name associated with the account (in the "h…
Of course, this would still rely on the provider: it might be a great solution for large providers like Google which can implement ironclad formal verification procedures, but if you and the previous company self-hosted SSO, you control the response and can impersonate them completely.
Re: Google’s OAuth login doesn’t protect against purchasing a failed startup domain
#196Earlier quoted context omitted.
It all depends on how true this statement is: > “The sub claim changes in about 0.04% of logins from Log in with Google. For us, that's hundreds of users last week”.
Exactly. How is there an entire alarmist article and 165 comments on this thread. This comment, and it's legitimacy/factualness, is the only thing worth discussing . `sub` _IS_ the immutable reliable identifier. If it's not, (1) I want to see actual proof, not an anonymous rando (sorry, but this thread re-inforces how little I trust context-less comments like that), and (2) I'd want to hear a convincing argument that…
Re: Google’s OAuth login doesn’t protect against purchasing a failed startup domain
#197Earlier quoted context omitted.
It seems there are two possible problems. The first is whether taking over a lapsed domain allows you to takeover an existing Google Workspace (or Cloud Identity) organization. This it what houses the corporate email accounts and OAuth client registrations. If Google allows this scenario then the linked account takeover is simply one symptom / side effect among many. TFA is not clear on whether this step actually hap…
> That said, I'm still not clear how the second problem manifests if the old OAuth client creds (housed in the old Workspace org id) are invalid. As far as I understand, this is not a necessary step. The SP is configured to trust Google's public OAuth IdP, not a specific Google Workspace account. So there are no special secrets shared between the old Google Workspace account and, say, Slack. The Slack org trusts any…
So what happens is: 1. New Workspace org created with same (old) domain name 2. Same domain name is sent in `hd` property, existing email address sent in the `email` property, new uuid in the `sub` property.
If the app is only matching on email instead of sub, then it will grant access to previous user data. Additionally, even if it makes a new user based on the new sub, it may still grant access to other SP resources associated with the existing domain based on the email address or hd value.
Instead there needs to be something like `hd` but uniquely identifying the Workspace org entity itself, not just the domain.
Re: Google’s OAuth login doesn’t protect against purchasing a failed startup domain
#198It'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,…
Re: Google’s OAuth login doesn’t protect against purchasing a failed startup domain
#199This is a stupid article. 1. It starts with “Millions of Americans”. How does this relate in any way to Americans? 2. Gmail is not the problem 3. Consider registering a domain for 10 years. When the startup fails, delete all dns entries