Apparently Google removes pagerank from expired domains to prevent gamification of their Search Index.
Same should apply to OAuth, you would think.
Google’s OAuth login doesn’t protect against purchasing a failed startup domain
201–210 of 297 posts
Re: Google’s OAuth login doesn’t protect against purchasing a failed startup domain
#202How's this any different than buying an expired domain and doing a password reset .. anywhere?
-- Probably someone else already mentioned this in the comments here, I just couldn't see.
Re: Google’s OAuth login doesn’t protect against purchasing a failed startup domain
#203Earlier quoted context omitted.
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.
Yeah, this is the part I'm struggling with. This is absolutely not unique to google oauth, it genuinely seems like a misunderstanding of how the web manages trust. If you own the domain, you own all the property associated with the domain, including all the old email addresses. Magic links and password resets are all going to give the new owner access. Your best bet as a solution is to be using strict 2fa (ex - a yub…
I don't think the claim is that Google has introduced a totally novel vuln, just that they are a stable, trusted middleman who is failing to mitigate a common vuln where they can.
You don't abandon filing cabinets, but given that some percentage of startup failures are sudden and surprising and the people who could do something are unmotivated / unable to, it's not a best practice for a commercial landlord to put abandoned files on the street with a sign "free", files and all. Maybe they have a legal right to, but it's not how I would operate in that situation.
Re: Google’s OAuth login doesn’t protect against purchasing a failed startup domain
#204This isn't anything new, or exclusive to Google, or exclusive to OAuth.
My workmate hadn't used Facebook for many years and it was associated to an email on a custom domain. Said domain expired and somehow hackers/script kiddies/bots must have an email list, run a whois, buy the domain if expired, setup email, and do password resets across social media and common websites. His Facebook was stolen.
Re: Google’s OAuth login doesn’t protect against purchasing a failed startup domain
#205It'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,…
> a failure on DankStartup's part, to not shut down their business accounts
They seized operations, why should they be responsible for any other assets?
I mean ethically yes of course. But there's no law/obligations to make sure domains are closed.
Re: Google’s OAuth login doesn’t protect against purchasing a failed startup domain
#206Earlier quoted context omitted.
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…
You can put whatever you want in WHOIS, including just replicating the information that was there previously. What if the WHOIS email is an email on the domain in question? 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…
This led me to go do a deeper dive.
1) WHOIS has been partially replaced by RDAP although many ccTLDs don't support it yet (notably .au and .us for example). Spec for RDAP query results:
https://datatracker.ietf.org/doc/rfc8977/
2) RDAP does specify that the registration date should be of the last time registered - if a domain has lapsed and picked up by somebody else it's supposed to use the verb "reregistered". But of course, you're depending on the registrar to do that. It does look like "registered" is properly followed - I looked into some known cases of poached lapsed domains and checked their RDAPS and the registration date corresponds to the date the domain drop-caught but no past expiry or re-registration is listed (example[1]).
3) Either way, don't use the content of the WHOIS/RDAP, just the dates.
Re: Google’s OAuth login doesn’t protect against purchasing a failed startup domain
#207Re: Google’s OAuth login doesn’t protect against purchasing a failed startup domain
#208Okay, this made me curious if there was a technical solution to this that people could be providing using the existing tools available, and I think there is.
RDAP and WHOIS will return the creation date of a domain. These fields are controlled by the registrar not the registrant. That creation/registration date gets reset when the domain is lapsed and picked up by somebody new.
So, when doing any domain-name-based authentication (like email password resets) authenticators should look up the registration date of the domain name. If it's newer than the last time the user logged in using the domain name auth? That might be somebody who snatched the domain name.
Re: Google’s OAuth login doesn’t protect against purchasing a failed startup domain
#209Earlier quoted context omitted.
>>>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?
Part of my company dissolution process is to renew the domain name for 10 years to prevent exactly this
Yes, this. I also use a service to capture all emails (catch all) so that I can detect any loose ends that might have been overlooked. Services like ForwardMX or Cloudflare can do this for you at relatively low (or no) cost.
Re: Google’s OAuth login doesn’t protect against purchasing a failed startup domain
#210Earlier quoted context omitted.
>Then, the impostors in step #3 create a different google account with the same domain, and Google says "yeah, these are definitely the same guys as before", even though Google is fully capable of discerning that that is not the case; these are different people with a different workspace account, different names, different payment information, and so on, but Google is saying that if you're holding the domain you are…
Traditionally, SAML / OIDC trust is established using public/private keypairs. Each IdP/SP pair gets a unique combination. In this case, a domain changing hands would not allow the new owner to gain access to the old owner's accounts. In the case of Google OAuth, it's possible to forego this in order to allow any Google user from any Google workspace to login to your application. See the distinction between "public a…
[deleted]