16 ms·

Google’s OAuth login doesn’t protect against purchasing a failed startup domain

503 points by simiones 2y ago

CuteMemeCoin 2y ago
Apparently Google removes pagerank from expired domains to prevent gamification of their Search Index. Same should apply to OAuth, you would think.
simiones 2y ago
I would be curious if any other Identity Providers that implement OAuth have mitigations for this issue. If you used sign in with Microsoft or Okta or PingFederate, would those provide different claims to the service?
- ratg13 2y ago
  Every provider has their own set of flaws. Microsoft had a flaw for awhile where you could just change a user’s email to anything with no verification.. and if the SSO implementer was only checking the email field, you could impersonate anyone.
- p_ing 2y ago
  Ideally the trust with the SP would be using a cert. This requires the SP to implement this portion of the standard and the IT department to follow through with implementing a cert. The cert can be self-generated, so there isn't a cost for the cert itself.
mcflubbins 2y ago
> 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. Sad how the only way to get Google's attention to make enough noise about something...
- dylan604 2y ago
  $1337 is a very curious amount. Surely, someone was being clever???
  - chasemiller 2y ago
    yeah, google likes to have fun with the Bug Bounty program. See: https://bughunters.google.com/about/rules/google-friends/6625378258649088/google-and-alphabet-vulnerability-reward-program-vrp-rules#reward-amounts-for-security-vulnerabilities https://bughunters.google.com/about/rules/google-friends/662...
    - dylan604 2y ago
      it's funny that all of the soul has not been sucked out of the entire company
  - mega_dingus 2y ago
    It's leetspeak It spells "leet" - see https://en.wikipedia.org/wiki/Leet https://en.wikipedia.org/wiki/Leet You're too young to have used BBSes :)
    - dylan604 2y ago
      What are you on about? You clearly missed the sarcasm.
      - deleted 2y ago
        [deleted]
      - richbell 2y ago
        Your comment didn't seem obviously sarcastic. Intent is hard to convey over text.
robertlagrant 2y ago
The "millions of accounts" is highly speculative, is it not? It relies on the idea that failed startups keep their SAAS accounts enabled, rather than offboarding correctly.
- toss1 2y ago
  >> is highly speculative, is it not? I'd say NOT. Shutdown of a small company running out of funds is rarely fully orderly. Critical things may get taken care of, but everything is unlikely, as people have already left. Plus, with things like already-paid-in accounts, there's even an incentive to keep them open until the term expires, e.g., why not keep the prepaid ChatGPT API account live for execs and techs to use between jobs? Just like wiping hard drives on EOL computers — everyone should do it every time, but people are always finding full HDDs and SSDs on eBay and Craigslist...
  - bpodgursky 2y ago
    Not just this, but execs and employees like to keep websites live for a while while they job-hunt (otherwise their resume has dead links). And ideally keep their name@startup.com email working. But to keep those running requires a long tail of "live" DNS and finance stuff you can't quite close out.
    - dylan604 2y ago
      Wouldn't it be cheaper just to pay for the domain registration for an extended time like 10 years vs the 1 or 2 year options?
  - dylan604 2y ago
    also, there are lots of non-technical people running small businesses that use G services because that's all they know. They can barely operate them let alone be cognizant of things like this "exploit".
- hangonhn 2y ago
  You would think that because you're a reasonable person. However at my previous startup, which no longer exists, the new CEO failed to save the company and parachuted out so fast that the company who later acquired the startup couldn't get the domain name transferred to them because the CEO and CTO were both gone. They had to bring back the predecessor CEO because he was still able to log into the registrar to transfer the domain. In the case of a fire, some less than conscientious people will fend for themselves first and don't give a second thought to anyone else.
richbell 2y ago
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.
- verdverm 2y ago
  We've also seen this in the dependency management ecosystem.
stackghost 2y ago
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, since they're providing service to a defunct business entity who can't pay its bills? To describe this as a vuln in oauth doesn't really make sense to me.
- ajross 2y ago
  The contention isn't that you can impersonate DankStartup, that's obviously not a vulnerability since you are indeed the domain owner. It's that former entities with DankStartup accounts might have used OAuth to create relationships of their own. And when the startup folds, they don't magically disappear. Basically if Sally, the CTO of DankStartup, signed up for Taskrabbit or whatnot, it's possible for you as the owner of the domain to impersonate Sally in the context of that relationship. Obviously the root cause here is that someone misused an account to do something not related to the business. And the actual impact is probably low since high value services tend strongly not to take tiny email domains as identity roots (i.e. sally@dankstartup.com clearly doesn't have a Vanguard account to steal). So... like most security announcements it's oversold and spun. But it's real enough as I read it.
  - simiones 2y ago
    > Basically if Sally, the CTO of DankStartup, signed up for Taskrabbit or whatnot, it's possible for you as the owner of the domain to impersonate Sally in the context of that relationship. I don't think this is the issue, unless someone went to some pretty extreme lengths. Configuring OAuth such that the company Google Workspaces account is recognized by Taskrabbit as a valid SSO option is not as simple as signing up to Taskrabbit with your company email instead of personal email.
    - nijave 2y ago
      Even then (in my experience) it's pretty common to setup an email based account and it will auto link to an oauth one that already exists. Even if Google revoked oauth, many platforms let you use the email directly to login
rdtsc 2y ago
> Shmoocon talk accepted - Dec 9, 2024, Google re-opens issue - Dec 19, 2024 Wondering what the internal process there was at Google? Is someone's job to cruise around the various conferences and dev events to look for any Google mentions and report back. Did Google really consider it an issue or just wanted it avoid looking bad in public after the talk was accepted.
- dylan604 2y ago
  Yes, there are roles where people do nothing but search their names/products/etc specifically to see what people are saying. Hell, some people do it on themselves to the point there are phrases like "vanity search" or "egosurfing"
- richbell 2y ago
  > Is someone's job to cruise around the various conferences and dev events to look for any Google mentions and report back. Someone in Google's security team likely saw the talk, or the original blog post, and pushed internally for them to award something.
  - ongy 2y ago
    Yea. The leet amount of payout seems like this was someone saying that the classification was technically correct, but it's worth fixing either way and it'd be nice to pay an amount.
andrewstuart2 2y ago
This 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 and that's what we use it for, but beyond that links will be saved, email addresses will be added to databases and address books alike, and that's more or less a reality of most systems. For example, my snail mail (and occasionally packages) is still mistakenly delivered to my former addresses from time to time just because it's hard to track who has that address, and update it everywhere. The same goes for internet infrastructure.
- simondanerd 2y ago
  I was able to take over an Instagram account because I received a password reset email to a domain catch all address that I'd set up years ago. Turns out it was a whole brand, but they refuse to change the email address and don't understand that I'm going to shut it all down. It totally makes my site look bad (it was an adultish brand and I was working on a community project) and I now have the power (and ability to do whatever with the account and any other that I happen upon with an email at that domain.
- gmuslera 2y ago
  At least it counts as a new category on the "It's DNS fault" list.
- Pxtl 2y ago
  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 they log in ask them to update or re-confirm their email address, and if they try to password reset they can't use an unconfirmed email address. Yes that's more tricky work. Authentication is hard. Nobody should be DIYing authentication anymore in this day and age, it's just too much.
tom1337 2y ago
Is this really an issue? Back when I implemented Google OAuth I used the "sub" that Google gave me as well as the email. I'd wager that Google does not re-use a sub for the same E-Mail so if the account is deleted and then somebody grabs the domain and re-created the account they'd have the same E-Mail but a different sub which would make the login fail. Seems to not be an issue in Google's OAuth Flow but rather the implementation on services like ChatGPT and so on?! EDIT: Just read that they claim that “The sub claim changes in about 0.04% of logins from Log in with Google” - never had this happen in the past years but if this is true then I guess thats a bad thing.
- efrowning 2y ago
  Are your users primarily using gmail accounts or are they using accounts from custom domains? TFA does't say exactly, but I wonder if this stat only applies to users with custom domains rather than @gmail accounts.
erincandescent 2y ago
> 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/onboarding/offboarding system resulted in the account being deleted and recreated. 2. is sensible, and is just a versioned version of the `hd` claim.
- anon84873628 2y ago
  1. Yep, your hypothesis seems likely. Consumer gmail addresses can't be used again after they are deleted, but it seems in Workspace orgs they can be reused/reassigned after 20 days: https://support.google.com/a/answer/33314?hl=en&co=DASHER._Family%3DDomain-verified&oco=0#restore&zippy=%2Creuse-the-email-address https://support.google.com/a/answer/33314?hl=en&co=DASHER._F... 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.
  - nixosbestos 2y ago
    Reinforcing the face-palm at the heart of this, which is that anyone deciding to you know, just use email instead of asking why an immutable ID changed... just probably enabled information leakage. Seriously, I'm so thankful that my colleagues would be principaled about this and ask questions instead of just doing something to make it "work". Where "work" means some GSuite user probably logged into some other defunct GSuite user's RP-account.
    - jeroenhd 2y ago
      The slides claim that this problem happens almost 600 times per week. There's no way it makes sense to manually validate all of those sessions. The secure thing would be to kick those users out and tell them to go figure out with Google why their account IDs keep changing. The easy and more profitable solution is to just use the email address as an account ID and keep the customers. Google did re-open the bug so I think there may be something wrong on Google's side, but for 99% of companies just using the `sub` value like it's intended to won't cause anyone any headache.
banger180 2y ago
> “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 those new user account should get assigned a new `sub`.
- caleblloyd 2y ago
  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.
  - loginatnine 2y ago
    At my current company, if an employee leave and come back, they'll keep the same OID in Entra but they'll get a new `sub` in Google workspace. We had to put in place a process to be able to use an internal tool that used the login with Google. That's most likely dependant on how the IT department handled the deprovisioning/provisioning of users in our Google Workspace, I unfortunately don't have the details for that.
  - banger180 2y ago
    > I wonder what action is causing the sub to change like the author suggests is happening. Indeed this would be very interesting. This issue is also very similar to CVE-2024-25618. What we did to mitigate this is the following: - Federated login with OIDC - Look for a user based on the sub claim - If they are found: authenticate that user and optionally update their profile (email, name, ...) based on then new id claims. - Else look for a user matching on the `email` claim and link the `sub` to that user - If no user is found create a new one
- saguntum 2y ago
  That sub identifier changing without the underlying user changing may be the core of the bug. It's not fully clear from the post IMO. I posted a little breakdown here: https://news.ycombinator.com/item?id=42701030 https://news.ycombinator.com/item?id=42701030 I don't think the article clearly states one way or another whether those 0.04% of sub claims changing are legitimate end user changes or not. If those sub changes are legitimately the Google Account changing, I don't think that's a bug on Google's part, but rather is a problem on the clients' side for not validating the sub claim. If the sub is changing without the Google Account user actually changing, maybe something internally at Google is swapping out those IDs when it shouldn't be. It doesn't look like a UUID from the example I saw, so maybe there's some code somewhere to just change the user's ID if there's a collision or something? Interestingly, I don't think Google claims that Sign in with Google is fully OIDC-compliant. At least in the overview I linked in my comment, they compare the implementation to OAuth+OIDC, but I'm not sure they claim to be 100% spec compliant.
bananapub 2y ago
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.
deleted 2y ago
[deleted]
_pete_ 2y ago
Thankfully, apparently this only affects Americans.
- lysace 2y ago
  :-)
loginatnine 2y ago
I 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-reference#credential https://developers.google.com/identity/gsi/web/reference/js-...
- Timshel 2y ago
  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”.
  - loginatnine 2y ago
    I've been working with an app that uses Google to login for the past 10 years, and I've had problems with sub changing when these situations happened : - Domain change - Company being bought by another one and being integrated in their Google Workspace - Employee leaving and coming back To us, it's very very far from the quoted 0.04% which is to me very high. I had to deal with it 5-6 times in the past 10 years but of course that number will vary depending on the usage of your app and I'm not gonna venture and put a percentage on it.
    - herczegzsolt 2y ago
      In my opponion, all of those cases very well justify a manual check, or some sort of extended identification before the user is let in. It indicates a deeper cultural issue of "convenience/profit over security" if those are sufficient reasons to not check the sub parameter.
ciaovietnam 2y ago
The email returned by OAuth providers is not always verified and thus cannot be trusted, anyone relies on the email as the ID is open to compromise. The sub claim should always be used as the ID, if you can prove that "the sub claim changes in about 0.04% of logins" then it's Google flaw and they should fix it, otherwise it isn't and there is no need to add another ID to the claim.
riffic 2y ago
Google may have quickly closed the original report because a company like that is soooo overwhelmed with garbage security reports and at first glance it is noise, not an actionable item to fix. there's a term for this that I can't quite recall off the top of my head. Bug Bounty Trolling?
swframe2 2y ago
Related maybe, I got a new phone number and I was able to use it to sign into the previous owner's account at a site that uses 2FA. I noticed it when I tried to setup a new account for myself. The website wouldn't allow it but it happily allowed to me access the previous owner's account. It was inconsistent, removing the phone from their account required their password but changing many other important fields didn't.
maerF0x0 2y ago
Seems like we need a chain of custody for domains, not just current ownership. Kinda like real estate. And then accounts are tied not just to the ownership state, but also the ownership instance ID. Just don't tell the web 3.0 folks cause I don't necessarily mean a blockchain.
- verdverm 2y ago
  Web 3 already tried this, it was called Handshake. I think their downfall is they wanted to replace ICANN / DNS rather than work with and alongside the current system.
  - ycombinatrix 2y ago
    shame, ICANN sucks
    - verdverm 2y ago
      I would argue the crypto bros are worse
      - ycombinatrix 2y ago
        crypto bros are annoying but at least they're doing their own thing. ICANN is actively screwing us.
        verdverm 2y ago
        If crypto bros took over the DNS system, it would no longer be them doing their own thing and we would all be getting screwed harder by the more deeply and insidiously misaligned incentives that come with crypto coin projects Anything that gets put on the blockchain gets a secondary derivatives market that then impacts your own project. There is nothing you can do about this, they are created independently and can live on a different blockchain. They are so obsessed with financializing everything and turning it into a market where they can skim off everything out there
seeknotfind 2y ago
Don't let domains you use lapse. Never get rid of a phone number.
- ycombinatrix 2y ago
  A lot of these new TLDs have variable registration fees. They're going to price a lot of people out of renewals.
SillyUsername 2y ago
Well they have kind of known about this kind of problem for 14 years https://issuetracker.google.com/issues/35889152?pli=1 https://issuetracker.google.com/issues/35889152?pli=1 although this is not a domain issue it is one where people can't unlink from company project ownership.
r00tbeer 2y ago
Avoiding this scenario is why Google will renew all the domains for every startup it has ever acquired in perpetuity.
somanyphotons 2y ago
Domains are for life, you can never let them lapse
dvydra2 2y ago
This actually happened to me a few years ago when I closed my consulting company. My bad, I know. My domain was taken over by someone in Vietnam. Back then, he was actually able to see my old emails via the Google Apps. Grandfathered free Apps accounts was a big part of the value proposition. He demanded $500 to delete my emails and docs. I offered $50 for his trouble since I recognized that I was at least partially at fault but he refused. To his bad luck, one of my main clients was Google itself. I reported him via my internal connections and the next day got the following email: "Oh my G-d, all forty of the domains I bought got Google Apps cancelled".
pfooti 2y ago
I think the problem is here in the doc: 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.
throw0101c 2y ago
In iSCSI, there are a few options for addressing the block storage devices, with one being the iSCSI Qualified Name (IQN) that uses the domain name. But it includes a timestamp: - A date code, in yyyy-mm format. This date MUST be a date during which the naming authority owned the domain name used in this format, and SHOULD be the first month in which the domain name was owned by this naming authority at 00:01 GMT of the first day of the month. This date code uses the Gregorian calendar. All four digits in the year must be present. Both digits of the month must be present, with January == "01" and December == "12". The dash must be included. * https://datatracker.ietf.org/doc/html/rfc3720#section-3.2.6.3.1 https://datatracker.ietf.org/doc/html/rfc3720#section-3.2.6.... * https://en.wikipedia.org/wiki/ISCSI#Addressing https://en.wikipedia.org/wiki/ISCSI#Addressing iqn.2001-04.com.example.storage:tape.sys1.xyz iqn.2000-02.edu.example.cs:users.oaks:proto.target4 * https://datatracker.ietf.org/doc/html/rfc3721 https://datatracker.ietf.org/doc/html/rfc3721 Clever idea to note change of ownership situations.
Ronnie76er 2y ago
As others have noted, this feels like an issue in the relying parties not relying on the `sub` field to validate the user. It feels the exact same as this issue here: https://bhavukjain.com/blog/2020/05/30/zeroday-signin-with-apple https://bhavukjain.com/blog/2020/05/30/zeroday-signin-with-a.... In both, the details around the `sub` field, the field that should actually be used to identify the user, is poorly described. I would say that both of these feel a bit sensationalist, but then again, if relying parties are NOT using the sub field to validate users, they should be called out. It seems to be that a good way to make some money is find every such situation where RPs are not using sub, and submit vuln bugs.
paxys 2y ago
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 OAuth, or any OAuth at all. Nothing in that write-up makes sense.
- dml2135 2y ago
  I think part of the issue is that this is where the abstraction that we call "account ownership" starts to leak. You may correctly have access to an account through this scenario, but that does not make it your account. This becomes obviously when we consider an account at a bank, for example.
- bitpush 2y ago
  The staying power of a Google = bad article on HN top page is insane.
  - lysace 2y ago
    And the opposite: The half-life of an Apple = bad article on HN is insane in the other direction.
- walrus01 2y ago
  Yes, this about sums it up. If you take over a domain, you control its registrar records for what its authoritative nameservers are, so of course you can set it to your own custom nameservers and then define whatever MX you want to receive incoming mail flow. You don't even have to go to any effort of configuring working outbound mail. You just need to put up a very minimal zonefile with the MX defined, basic postfix email server with a catchall configuration and then receive any incoming emails for *@domain.com.
- okdood64 2y ago
  It's crazy that they do that only because "Google search bad now" or "Youtube bad now".
landryraccoon 2y ago
If you think this is bad, wait until you move physical addresses and don’t notify all your creditors! Literally ANYONE who moves into your old house will have access to your bank statements, credit card bills, tax forms, auto registration and who knows what else. And it will all come plaintext and unencrypted!
- akovaski 2y ago
  Phone numbers too. Ah, but it's illegal to open mail addressed to someone else. (Although what if you change your legal name to match???!) Perhaps we need an electronic messaging service backed by the USPS.
ds 2y ago
Nearly a decade ago, there was a website called thehunt.com that basically ran out of money and some employees were acqui-hired by pinterest. All of the assets were left to rot and at the time the company was a good match for another startup of mine. So I reached out to the investors I found on crunchbase and asked if I could acquire everything. We worked out a deal and I did. The issue was the complete lack of people from the old company willing to assist and the complete lack of data for alot of things. There was 1 or 2 people who we could ping from the old company to ping who were super helpful, but the big thing was many things were just lost to time- passwords, history, code repos, etc.. Simply creating a new google apps account allowed us to get full access back to everything - We could even read old slack messages (even DMs!) by resetting each accounts password. The whole thing was shocking to say the least, but with that access we got back into literally every service they used and managed to get it up and running again within a week, which was a good thing because nearly every service it was using was threatening to shut it down every day for lack of payment. I think the solution here is actually way simpler than most make it out to be and could easily be a startup for someone: Create a startup that lets customers simply enter in domains. If the domain EVER goes into the "pendingDelete" status, inform the customer. The customer would be random SAAS's that want to protect against this type of attack and could simply choose to disallow access to any account that has had their domain go into that status.
- btown 2y ago
  Huh - it's almost like the mere existence of a pendingDelete in the history of a domain should make every email existing on that domain at that time eligible for https://haveibeenpwned.com/ https://haveibeenpwned.com/ .
citizenpaul 2y ago
It seems like there have been a number of security stories lately that essentially amount to. "no tech companies ever does cleanup" Which everyone on HN with a couple years or more experience should know is the norm. I expect a lot more of this to keep happening since companies will never really care about security without consequences ie a $10 fine for making $100 literally incentivies lack of security.
Ekaros 2y ago
How many recovery processes would depend on email. And it coming from right domain? Or changes in DNS. Or some other factor that domain holder could do. I don't think possible alternative scenarios would go down too well.
chavesn 2y ago
If oauth makes an authenticity claim, it should be true. Saying it's the same user when it's not is bad, clearly. in other words: Google could make a more accurate authenticity claim than they currently do. This problem would be worse without oauth, though, right? With plain email login, all they would need to do is "forgot password" and there wouldn't even be a way to tell. in other words: Email login would never be able to make a more accurate authenticity claim.
commterch1 2y ago
This 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
- perch56 2y ago
  I agree. Additionally, the authors haven’t considered data deletion policies. Most SaaS providers delete data within 30 to 90 days after contract termination. It’s unlikely that data from 100,000 failed startups, each using 20 to 30 SaaS applications, still exists.
zahlman 2y ago
One of the unintended side effects of Noscript is this sort of unintended hilarity: > These claims usually include: > hd (hosted domain): Specifies the domain, e.g., example.com. > email: The user's email address, e.g., [email protected]. The placeholder, hypothetical email address is being "protected" from web scraping. In the context of an article on a security website about identities being spoofed through email accounts.
commterch1 2y ago
This 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. Mitigation: Consider registering a domain for 10 years. When the startup fails, delete all dns entries
hansvm 2y ago
This feels similar in spirit to some service providers (*cough* Atlassian -- especially bad when they acquire other companies and push that bullshit on previously functional authentication systems) using ownership of a domain to assert ownership of an account using that domain. E.g.: 1. You create an account using an email associated with a domain. 2. The domain owner coughs up their protection money to Atlassian and proves ownership of the domain. 3. Your password-protected account is assigned to the domain owner. Your password and 2FA invalid. The domain owner can access your private data without your password and 2FA. Both TFA and the thing I described rely on broken, simplistic views of "domain ownership == account ownership".
ycombinatrix 2y ago
So the "sub" claim does work but the "staff engineer at a major tech company" doesn't want to fix it because it happens too often?
kbtombul 2y ago
How'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.
dankwizard 2y ago
This 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.
Pxtl 2y ago
Okay, 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.
- deleted 2y ago
  [deleted]
- efrowning 2y ago
  Sadly, this isn't fool-proof. Domains can go up for auction or backorder on a registrar, and they won't update the registration date if the domain is purchased this way since the registrar can consider this a transfer. It's a signal, for sure, but it will miss cases. It will also miss transfers sometimes, depending on the registrar.
  - Pxtl 2y ago
    I was trying to find cases of it happening historically so I could check the RDAP record to see how domain registrars use it in practice... and yeah, the registrars seem to ignore a lot of the spec. While they do generally seem to follow the "lapse and re-register = new registration date", I can see how your example is something they probably would break. RDAP records don't appear to show historical expirations and reinstantiations and re-registrations despite the spec describing events for that. It's always just the basic event entries: Registration date, last changed date, future expiry date. Even with domains that have well known dramatic histories. Which tells me the RDAP spec is not really enforced. While I dislike "blockchain all the things" I can definitely see the argument for a blockchain-like global shared public ledger (albeit a not for-profit proof-of-work one) with full history for this sort of data.
bhartzer 2y ago
I don't think this has anything to do with Google's OAuth. This issue is literally with every single expired domain name out there. All one has to do is register the expired domain and look at all the emails sent to that domain. Granted, Google "could" do something, but I don't think it's Google's responsibility to police expired domain names. What am I missing here?
- jeroenhd 2y ago
  Google promises to use a different `sub` claim for every account, even if you reuse the domain name. However, according to the talk, the `sub` claim isn't stable in normal scenarios, so developers don't use that like they're supposed to. Google should fix the `sub` problem if the problem is on their side (and not, for instance, related to user accounts impersonation or recreated user accounts, which are expected to fail this check). Everyone integrating with Google should use the `sub` claim like they're supposed to. Of course this approach doesn't help if a domain admin can recover the original workspace account (rather than simply re-registering the domain with Google), but that can easily be solved by not having the domain admin accounts use the domain they're hosted on.
fastest963 2y ago
We take the OAuth2 token and make a call to the People API [0] to get the Person resourceName. Not sure if this is more stable than "sub" but we completely ignore that. [0] https://developers.google.com/people/api/rest/v1/people/get https://developers.google.com/people/api/rest/v1/people/get
deathanatos 2y ago
> 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. I've had a staff SWE also claim to me that they generated colliding UUIDv4s, and a separate staff SWE who worked in GIS claim that circles only exist in map projections and they're always distorted, and that you cannot have a circle IRL, nor project it onto a projection. Neither's attention to quality, or rather, lack thereof, could cash those outlandish claims. There is a simple explanation here: Your staff SWE is wrong. `sub` is the claim you're looking for. Extraordinary claims require at least a trifling of proof. Or, what can be asserted without evidence can also be dismissed without evidence. And this alleges to be a security blog. As a writer with that target audience, you should know this is going to be the objection to the thesis that your reader will have, and you attempt to just handwave it away…?
- j16sdiz 2y ago
  > I've had a staff SWE also claim to me that they generated colliding UUIDv4s, UUIDv4 is random. Could be a bad PRNG, or just very very very bad luck. > and a separate staff SWE who worked in GIS claim that circles only exist in map projections and they're always distorted, and that you cannot have a circle IRL, nor project it onto a projection. It is insanely difficult to project circles. Most of time we just pretend it never exist.
  - deathanatos 2y ago
    > or just very very very bad luck. You're underestimating the odds. The odds aren't "bad luck", the odds are "statistical impossibility". Literally any other explanation holds with orders of magnitude higher certainty. > It is insanely difficult to project circles. Most of time we just pretend it never exist. Open Google maps, find the equator. That's a circle, rendered on a projection. (But far from the only example possible.) (And lest I get more objections, a perfectly spherical earth was also an assumption of this assertion that circles don't exist. My coworker attempted to draw/show a circle onto an actual sphere we fortuitously had handy, and no dice.) (Note the other way exists too: a projection can have a circle rendered on it, though it wouldn't be a circle on an actual sphere.)
- 2y ago
necovek 2y ago
Assuming most of the problem is that federated services only rely on email address from OidC login, I wonder if Google could start offering user+unique-workspace-id@company.domain as the email address for any new workspace/user/federated login? Obviously, Google needs to control "unique-workspace-id". Does not solve it for existing customers and any federated service they logged into, though if included alongside the simple email, federated services could gradually move to it and announce once they are "ready" so workspace admins can configure them to start accepting only new, safe email addresses.
lovasoa 2y ago
Does anyone here know more about the unreliability of Google's sub claim? I am using it, and have never had issues with it, but this post seems to just dismiss it without more details. When does Google change the subject of a token for a given user account?
xinayder 2y ago
I fail to see how this is Google's problem and as much as it pains me to say this, I agree with Google. I believe it is more the downstream providers fault for not terminating inactive accounts, and the failed startup's for not properly deleting their Google accounts. Google can mitigate this as the author mentioned, but this is not their responsibility. They shouldn't be held liable because failed startups were stupid to not delete their data.
jimjonah 2y ago
It sounds like there’s a bug with the “sub” field. The author is stating that they can’t use it as a unique identifier for the user. Isn’t that the root of the problem? A new domain owner could try to reuse email addresses, but since the domain is now in a new workspace the sub should be different and downstream services shouldn’t second guess that. Am I wrong about this?
moi2388 2y ago
For the people not understanding the security risk, or how this would be something Google needs to solve, have a look at the claims of Microsoft Id token claims, and how their use of multiple guid claims completely eliminates this problem: https://learn.microsoft.com/en-us/entra/identity-platform/id-token-claims-reference https://learn.microsoft.com/en-us/entra/identity-platform/id...

503 points by simiones 2y ago

Apparently Google removes pagerank from expired domains to prevent gamification of their Search Index. Same should apply to OAuth, you would think.

simiones 2y ago

I would be curious if any other Identity Providers that implement OAuth have mitigations for this issue. If you used sign in with Microsoft or Okta or PingFederate, would those provide different claims to the service?

ratg13 2y ago
Every provider has their own set of flaws. Microsoft had a flaw for awhile where you could just change a user’s email to anything with no verification.. and if the SSO implementer was only checking the email field, you could impersonate anyone.
p_ing 2y ago
Ideally the trust with the SP would be using a cert. This requires the SP to implement this portion of the standard and the IT department to follow through with implementing a cert. The cert can be self-generated, so there isn't a cost for the cert itself.

mcflubbins 2y ago

> 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. Sad how the only way to get Google's attention to make enough noise about something...

dylan604 2y ago
$1337 is a very curious amount. Surely, someone was being clever???
- chasemiller 2y ago
  yeah, google likes to have fun with the Bug Bounty program. See: https://bughunters.google.com/about/rules/google-friends/6625378258649088/google-and-alphabet-vulnerability-reward-program-vrp-rules#reward-amounts-for-security-vulnerabilities https://bughunters.google.com/about/rules/google-friends/662...
  - dylan604 2y ago
    it's funny that all of the soul has not been sucked out of the entire company
- mega_dingus 2y ago
  It's leetspeak It spells "leet" - see https://en.wikipedia.org/wiki/Leet https://en.wikipedia.org/wiki/Leet You're too young to have used BBSes :)
  - dylan604 2y ago
    What are you on about? You clearly missed the sarcasm.
    - deleted 2y ago
      [deleted]
    - richbell 2y ago
      Your comment didn't seem obviously sarcastic. Intent is hard to convey over text.

robertlagrant 2y ago

The "millions of accounts" is highly speculative, is it not? It relies on the idea that failed startups keep their SAAS accounts enabled, rather than offboarding correctly.

toss1 2y ago
>> is highly speculative, is it not? I'd say NOT. Shutdown of a small company running out of funds is rarely fully orderly. Critical things may get taken care of, but everything is unlikely, as people have already left. Plus, with things like already-paid-in accounts, there's even an incentive to keep them open until the term expires, e.g., why not keep the prepaid ChatGPT API account live for execs and techs to use between jobs? Just like wiping hard drives on EOL computers — everyone should do it every time, but people are always finding full HDDs and SSDs on eBay and Craigslist...
- bpodgursky 2y ago
  Not just this, but execs and employees like to keep websites live for a while while they job-hunt (otherwise their resume has dead links). And ideally keep their name@startup.com email working. But to keep those running requires a long tail of "live" DNS and finance stuff you can't quite close out.
  - dylan604 2y ago
    Wouldn't it be cheaper just to pay for the domain registration for an extended time like 10 years vs the 1 or 2 year options?
- dylan604 2y ago
  also, there are lots of non-technical people running small businesses that use G services because that's all they know. They can barely operate them let alone be cognizant of things like this "exploit".
hangonhn 2y ago
You would think that because you're a reasonable person. However at my previous startup, which no longer exists, the new CEO failed to save the company and parachuted out so fast that the company who later acquired the startup couldn't get the domain name transferred to them because the CEO and CTO were both gone. They had to bring back the predecessor CEO because he was still able to log into the registrar to transfer the domain. In the case of a fire, some less than conscientious people will fend for themselves first and don't give a second thought to anyone else.

richbell 2y ago

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.

verdverm 2y ago
We've also seen this in the dependency management ecosystem.

stackghost 2y ago

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, since they're providing service to a defunct business entity who can't pay its bills? To describe this as a vuln in oauth doesn't really make sense to me.

ajross 2y ago
The contention isn't that you can impersonate DankStartup, that's obviously not a vulnerability since you are indeed the domain owner. It's that former entities with DankStartup accounts might have used OAuth to create relationships of their own. And when the startup folds, they don't magically disappear. Basically if Sally, the CTO of DankStartup, signed up for Taskrabbit or whatnot, it's possible for you as the owner of the domain to impersonate Sally in the context of that relationship. Obviously the root cause here is that someone misused an account to do something not related to the business. And the actual impact is probably low since high value services tend strongly not to take tiny email domains as identity roots (i.e. sally@dankstartup.com clearly doesn't have a Vanguard account to steal). So... like most security announcements it's oversold and spun. But it's real enough as I read it.
- simiones 2y ago
  > Basically if Sally, the CTO of DankStartup, signed up for Taskrabbit or whatnot, it's possible for you as the owner of the domain to impersonate Sally in the context of that relationship. I don't think this is the issue, unless someone went to some pretty extreme lengths. Configuring OAuth such that the company Google Workspaces account is recognized by Taskrabbit as a valid SSO option is not as simple as signing up to Taskrabbit with your company email instead of personal email.
  - nijave 2y ago
    Even then (in my experience) it's pretty common to setup an email based account and it will auto link to an oauth one that already exists. Even if Google revoked oauth, many platforms let you use the email directly to login

rdtsc 2y ago

> Shmoocon talk accepted - Dec 9, 2024, Google re-opens issue - Dec 19, 2024 Wondering what the internal process there was at Google? Is someone's job to cruise around the various conferences and dev events to look for any Google mentions and report back. Did Google really consider it an issue or just wanted it avoid looking bad in public after the talk was accepted.

dylan604 2y ago
Yes, there are roles where people do nothing but search their names/products/etc specifically to see what people are saying. Hell, some people do it on themselves to the point there are phrases like "vanity search" or "egosurfing"
richbell 2y ago
> Is someone's job to cruise around the various conferences and dev events to look for any Google mentions and report back. Someone in Google's security team likely saw the talk, or the original blog post, and pushed internally for them to award something.
- ongy 2y ago
  Yea. The leet amount of payout seems like this was someone saying that the classification was technically correct, but it's worth fixing either way and it'd be nice to pay an amount.

andrewstuart2 2y ago

This 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 and that's what we use it for, but beyond that links will be saved, email addresses will be added to databases and address books alike, and that's more or less a reality of most systems. For example, my snail mail (and occasionally packages) is still mistakenly delivered to my former addresses from time to time just because it's hard to track who has that address, and update it everywhere. The same goes for internet infrastructure.

simondanerd 2y ago
I was able to take over an Instagram account because I received a password reset email to a domain catch all address that I'd set up years ago. Turns out it was a whole brand, but they refuse to change the email address and don't understand that I'm going to shut it all down. It totally makes my site look bad (it was an adultish brand and I was working on a community project) and I now have the power (and ability to do whatever with the account and any other that I happen upon with an email at that domain.
gmuslera 2y ago
At least it counts as a new category on the "It's DNS fault" list.
Pxtl 2y ago
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 they log in ask them to update or re-confirm their email address, and if they try to password reset they can't use an unconfirmed email address. Yes that's more tricky work. Authentication is hard. Nobody should be DIYing authentication anymore in this day and age, it's just too much.

tom1337 2y ago

Is this really an issue? Back when I implemented Google OAuth I used the "sub" that Google gave me as well as the email. I'd wager that Google does not re-use a sub for the same E-Mail so if the account is deleted and then somebody grabs the domain and re-created the account they'd have the same E-Mail but a different sub which would make the login fail. Seems to not be an issue in Google's OAuth Flow but rather the implementation on services like ChatGPT and so on?! EDIT: Just read that they claim that “The sub claim changes in about 0.04% of logins from Log in with Google” - never had this happen in the past years but if this is true then I guess thats a bad thing.

efrowning 2y ago
Are your users primarily using gmail accounts or are they using accounts from custom domains? TFA does't say exactly, but I wonder if this stat only applies to users with custom domains rather than @gmail accounts.

erincandescent 2y ago

> 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/onboarding/offboarding system resulted in the account being deleted and recreated. 2. is sensible, and is just a versioned version of the `hd` claim.

anon84873628 2y ago
1. Yep, your hypothesis seems likely. Consumer gmail addresses can't be used again after they are deleted, but it seems in Workspace orgs they can be reused/reassigned after 20 days: https://support.google.com/a/answer/33314?hl=en&co=DASHER._Family%3DDomain-verified&oco=0#restore&zippy=%2Creuse-the-email-address https://support.google.com/a/answer/33314?hl=en&co=DASHER._F... 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.
- nixosbestos 2y ago
  Reinforcing the face-palm at the heart of this, which is that anyone deciding to you know, just use email instead of asking why an immutable ID changed... just probably enabled information leakage. Seriously, I'm so thankful that my colleagues would be principaled about this and ask questions instead of just doing something to make it "work". Where "work" means some GSuite user probably logged into some other defunct GSuite user's RP-account.
  - jeroenhd 2y ago
    The slides claim that this problem happens almost 600 times per week. There's no way it makes sense to manually validate all of those sessions. The secure thing would be to kick those users out and tell them to go figure out with Google why their account IDs keep changing. The easy and more profitable solution is to just use the email address as an account ID and keep the customers. Google did re-open the bug so I think there may be something wrong on Google's side, but for 99% of companies just using the `sub` value like it's intended to won't cause anyone any headache.

banger180 2y ago

> “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 those new user account should get assigned a new `sub`.

caleblloyd 2y ago
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.
- loginatnine 2y ago
  At my current company, if an employee leave and come back, they'll keep the same OID in Entra but they'll get a new `sub` in Google workspace. We had to put in place a process to be able to use an internal tool that used the login with Google. That's most likely dependant on how the IT department handled the deprovisioning/provisioning of users in our Google Workspace, I unfortunately don't have the details for that.
- banger180 2y ago
  > I wonder what action is causing the sub to change like the author suggests is happening. Indeed this would be very interesting. This issue is also very similar to CVE-2024-25618. What we did to mitigate this is the following: - Federated login with OIDC - Look for a user based on the sub claim - If they are found: authenticate that user and optionally update their profile (email, name, ...) based on then new id claims. - Else look for a user matching on the `email` claim and link the `sub` to that user - If no user is found create a new one
saguntum 2y ago
That sub identifier changing without the underlying user changing may be the core of the bug. It's not fully clear from the post IMO. I posted a little breakdown here: https://news.ycombinator.com/item?id=42701030 https://news.ycombinator.com/item?id=42701030 I don't think the article clearly states one way or another whether those 0.04% of sub claims changing are legitimate end user changes or not. If those sub changes are legitimately the Google Account changing, I don't think that's a bug on Google's part, but rather is a problem on the clients' side for not validating the sub claim. If the sub is changing without the Google Account user actually changing, maybe something internally at Google is swapping out those IDs when it shouldn't be. It doesn't look like a UUID from the example I saw, so maybe there's some code somewhere to just change the user's ID if there's a collision or something? Interestingly, I don't think Google claims that Sign in with Google is fully OIDC-compliant. At least in the overview I linked in my comment, they compare the implementation to OAuth+OIDC, but I'm not sure they claim to be 100% spec compliant.

bananapub 2y ago

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.

deleted 2y ago

[deleted]

_pete_ 2y ago

Thankfully, apparently this only affects Americans.

lysace 2y ago
:-)

loginatnine 2y ago

I 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-reference#credential https://developers.google.com/identity/gsi/web/reference/js-...

Timshel 2y ago
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”.
- loginatnine 2y ago
  I've been working with an app that uses Google to login for the past 10 years, and I've had problems with sub changing when these situations happened : - Domain change - Company being bought by another one and being integrated in their Google Workspace - Employee leaving and coming back To us, it's very very far from the quoted 0.04% which is to me very high. I had to deal with it 5-6 times in the past 10 years but of course that number will vary depending on the usage of your app and I'm not gonna venture and put a percentage on it.
  - herczegzsolt 2y ago
    In my opponion, all of those cases very well justify a manual check, or some sort of extended identification before the user is let in. It indicates a deeper cultural issue of "convenience/profit over security" if those are sufficient reasons to not check the sub parameter.

ciaovietnam 2y ago

The email returned by OAuth providers is not always verified and thus cannot be trusted, anyone relies on the email as the ID is open to compromise. The sub claim should always be used as the ID, if you can prove that "the sub claim changes in about 0.04% of logins" then it's Google flaw and they should fix it, otherwise it isn't and there is no need to add another ID to the claim.

riffic 2y ago

Google may have quickly closed the original report because a company like that is soooo overwhelmed with garbage security reports and at first glance it is noise, not an actionable item to fix. there's a term for this that I can't quite recall off the top of my head. Bug Bounty Trolling?

swframe2 2y ago

Related maybe, I got a new phone number and I was able to use it to sign into the previous owner's account at a site that uses 2FA. I noticed it when I tried to setup a new account for myself. The website wouldn't allow it but it happily allowed to me access the previous owner's account. It was inconsistent, removing the phone from their account required their password but changing many other important fields didn't.

maerF0x0 2y ago

Seems like we need a chain of custody for domains, not just current ownership. Kinda like real estate. And then accounts are tied not just to the ownership state, but also the ownership instance ID. Just don't tell the web 3.0 folks cause I don't necessarily mean a blockchain.

verdverm 2y ago
Web 3 already tried this, it was called Handshake. I think their downfall is they wanted to replace ICANN / DNS rather than work with and alongside the current system.
- ycombinatrix 2y ago
  shame, ICANN sucks
  - verdverm 2y ago
    I would argue the crypto bros are worse
    - ycombinatrix 2y ago
      crypto bros are annoying but at least they're doing their own thing. ICANN is actively screwing us.
      - verdverm 2y ago
        If crypto bros took over the DNS system, it would no longer be them doing their own thing and we would all be getting screwed harder by the more deeply and insidiously misaligned incentives that come with crypto coin projects Anything that gets put on the blockchain gets a secondary derivatives market that then impacts your own project. There is nothing you can do about this, they are created independently and can live on a different blockchain. They are so obsessed with financializing everything and turning it into a market where they can skim off everything out there

seeknotfind 2y ago

Don't let domains you use lapse. Never get rid of a phone number.

ycombinatrix 2y ago
A lot of these new TLDs have variable registration fees. They're going to price a lot of people out of renewals.

SillyUsername 2y ago

Well they have kind of known about this kind of problem for 14 years https://issuetracker.google.com/issues/35889152?pli=1 https://issuetracker.google.com/issues/35889152?pli=1 although this is not a domain issue it is one where people can't unlink from company project ownership.

r00tbeer 2y ago

Avoiding this scenario is why Google will renew all the domains for every startup it has ever acquired in perpetuity.

somanyphotons 2y ago

Domains are for life, you can never let them lapse

dvydra2 2y ago

This actually happened to me a few years ago when I closed my consulting company. My bad, I know. My domain was taken over by someone in Vietnam. Back then, he was actually able to see my old emails via the Google Apps. Grandfathered free Apps accounts was a big part of the value proposition. He demanded $500 to delete my emails and docs. I offered $50 for his trouble since I recognized that I was at least partially at fault but he refused. To his bad luck, one of my main clients was Google itself. I reported him via my internal connections and the next day got the following email: "Oh my G-d, all forty of the domains I bought got Google Apps cancelled".

pfooti 2y ago

I think the problem is here in the doc: 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.

throw0101c 2y ago

In iSCSI, there are a few options for addressing the block storage devices, with one being the iSCSI Qualified Name (IQN) that uses the domain name. But it includes a timestamp: - A date code, in yyyy-mm format. This date MUST be a date during which the naming authority owned the domain name used in this format, and SHOULD be the first month in which the domain name was owned by this naming authority at 00:01 GMT of the first day of the month. This date code uses the Gregorian calendar. All four digits in the year must be present. Both digits of the month must be present, with January == "01" and December == "12". The dash must be included. * https://datatracker.ietf.org/doc/html/rfc3720#section-3.2.6.3.1 https://datatracker.ietf.org/doc/html/rfc3720#section-3.2.6.... * https://en.wikipedia.org/wiki/ISCSI#Addressing https://en.wikipedia.org/wiki/ISCSI#Addressing iqn.2001-04.com.example.storage:tape.sys1.xyz iqn.2000-02.edu.example.cs:users.oaks:proto.target4 * https://datatracker.ietf.org/doc/html/rfc3721 https://datatracker.ietf.org/doc/html/rfc3721 Clever idea to note change of ownership situations.

Ronnie76er 2y ago

As others have noted, this feels like an issue in the relying parties not relying on the `sub` field to validate the user. It feels the exact same as this issue here: https://bhavukjain.com/blog/2020/05/30/zeroday-signin-with-apple https://bhavukjain.com/blog/2020/05/30/zeroday-signin-with-a.... In both, the details around the `sub` field, the field that should actually be used to identify the user, is poorly described. I would say that both of these feel a bit sensationalist, but then again, if relying parties are NOT using the sub field to validate users, they should be called out. It seems to be that a good way to make some money is find every such situation where RPs are not using sub, and submit vuln bugs.

paxys 2y ago

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 OAuth, or any OAuth at all. Nothing in that write-up makes sense.

dml2135 2y ago
I think part of the issue is that this is where the abstraction that we call "account ownership" starts to leak. You may correctly have access to an account through this scenario, but that does not make it your account. This becomes obviously when we consider an account at a bank, for example.
bitpush 2y ago
The staying power of a Google = bad article on HN top page is insane.
- lysace 2y ago
  And the opposite: The half-life of an Apple = bad article on HN is insane in the other direction.
walrus01 2y ago
Yes, this about sums it up. If you take over a domain, you control its registrar records for what its authoritative nameservers are, so of course you can set it to your own custom nameservers and then define whatever MX you want to receive incoming mail flow. You don't even have to go to any effort of configuring working outbound mail. You just need to put up a very minimal zonefile with the MX defined, basic postfix email server with a catchall configuration and then receive any incoming emails for *@domain.com.
okdood64 2y ago
It's crazy that they do that only because "Google search bad now" or "Youtube bad now".

landryraccoon 2y ago

If you think this is bad, wait until you move physical addresses and don’t notify all your creditors! Literally ANYONE who moves into your old house will have access to your bank statements, credit card bills, tax forms, auto registration and who knows what else. And it will all come plaintext and unencrypted!

akovaski 2y ago
Phone numbers too. Ah, but it's illegal to open mail addressed to someone else. (Although what if you change your legal name to match???!) Perhaps we need an electronic messaging service backed by the USPS.

ds 2y ago

Nearly a decade ago, there was a website called thehunt.com that basically ran out of money and some employees were acqui-hired by pinterest. All of the assets were left to rot and at the time the company was a good match for another startup of mine. So I reached out to the investors I found on crunchbase and asked if I could acquire everything. We worked out a deal and I did. The issue was the complete lack of people from the old company willing to assist and the complete lack of data for alot of things. There was 1 or 2 people who we could ping from the old company to ping who were super helpful, but the big thing was many things were just lost to time- passwords, history, code repos, etc.. Simply creating a new google apps account allowed us to get full access back to everything - We could even read old slack messages (even DMs!) by resetting each accounts password. The whole thing was shocking to say the least, but with that access we got back into literally every service they used and managed to get it up and running again within a week, which was a good thing because nearly every service it was using was threatening to shut it down every day for lack of payment. I think the solution here is actually way simpler than most make it out to be and could easily be a startup for someone: Create a startup that lets customers simply enter in domains. If the domain EVER goes into the "pendingDelete" status, inform the customer. The customer would be random SAAS's that want to protect against this type of attack and could simply choose to disallow access to any account that has had their domain go into that status.

btown 2y ago
Huh - it's almost like the mere existence of a pendingDelete in the history of a domain should make every email existing on that domain at that time eligible for https://haveibeenpwned.com/ https://haveibeenpwned.com/ .

citizenpaul 2y ago

It seems like there have been a number of security stories lately that essentially amount to. "no tech companies ever does cleanup" Which everyone on HN with a couple years or more experience should know is the norm. I expect a lot more of this to keep happening since companies will never really care about security without consequences ie a $10 fine for making $100 literally incentivies lack of security.

Ekaros 2y ago

How many recovery processes would depend on email. And it coming from right domain? Or changes in DNS. Or some other factor that domain holder could do. I don't think possible alternative scenarios would go down too well.

chavesn 2y ago

If oauth makes an authenticity claim, it should be true. Saying it's the same user when it's not is bad, clearly. in other words: Google could make a more accurate authenticity claim than they currently do. This problem would be worse without oauth, though, right? With plain email login, all they would need to do is "forgot password" and there wouldn't even be a way to tell. in other words: Email login would never be able to make a more accurate authenticity claim.

commterch1 2y ago

This 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

perch56 2y ago
I agree. Additionally, the authors haven’t considered data deletion policies. Most SaaS providers delete data within 30 to 90 days after contract termination. It’s unlikely that data from 100,000 failed startups, each using 20 to 30 SaaS applications, still exists.

zahlman 2y ago

One of the unintended side effects of Noscript is this sort of unintended hilarity: > These claims usually include: > hd (hosted domain): Specifies the domain, e.g., example.com. > email: The user's email address, e.g., [email protected]. The placeholder, hypothetical email address is being "protected" from web scraping. In the context of an article on a security website about identities being spoofed through email accounts.

commterch1 2y ago

This 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. Mitigation: Consider registering a domain for 10 years. When the startup fails, delete all dns entries

hansvm 2y ago

This feels similar in spirit to some service providers (*cough* Atlassian -- especially bad when they acquire other companies and push that bullshit on previously functional authentication systems) using ownership of a domain to assert ownership of an account using that domain. E.g.: 1. You create an account using an email associated with a domain. 2. The domain owner coughs up their protection money to Atlassian and proves ownership of the domain. 3. Your password-protected account is assigned to the domain owner. Your password and 2FA invalid. The domain owner can access your private data without your password and 2FA. Both TFA and the thing I described rely on broken, simplistic views of "domain ownership == account ownership".

ycombinatrix 2y ago

So the "sub" claim does work but the "staff engineer at a major tech company" doesn't want to fix it because it happens too often?

kbtombul 2y ago

How'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.

dankwizard 2y ago

This 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.

Pxtl 2y ago

Okay, 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.

deleted 2y ago
[deleted]
efrowning 2y ago
Sadly, this isn't fool-proof. Domains can go up for auction or backorder on a registrar, and they won't update the registration date if the domain is purchased this way since the registrar can consider this a transfer. It's a signal, for sure, but it will miss cases. It will also miss transfers sometimes, depending on the registrar.
- Pxtl 2y ago
  I was trying to find cases of it happening historically so I could check the RDAP record to see how domain registrars use it in practice... and yeah, the registrars seem to ignore a lot of the spec. While they do generally seem to follow the "lapse and re-register = new registration date", I can see how your example is something they probably would break. RDAP records don't appear to show historical expirations and reinstantiations and re-registrations despite the spec describing events for that. It's always just the basic event entries: Registration date, last changed date, future expiry date. Even with domains that have well known dramatic histories. Which tells me the RDAP spec is not really enforced. While I dislike "blockchain all the things" I can definitely see the argument for a blockchain-like global shared public ledger (albeit a not for-profit proof-of-work one) with full history for this sort of data.

bhartzer 2y ago

I don't think this has anything to do with Google's OAuth. This issue is literally with every single expired domain name out there. All one has to do is register the expired domain and look at all the emails sent to that domain. Granted, Google "could" do something, but I don't think it's Google's responsibility to police expired domain names. What am I missing here?

jeroenhd 2y ago
Google promises to use a different `sub` claim for every account, even if you reuse the domain name. However, according to the talk, the `sub` claim isn't stable in normal scenarios, so developers don't use that like they're supposed to. Google should fix the `sub` problem if the problem is on their side (and not, for instance, related to user accounts impersonation or recreated user accounts, which are expected to fail this check). Everyone integrating with Google should use the `sub` claim like they're supposed to. Of course this approach doesn't help if a domain admin can recover the original workspace account (rather than simply re-registering the domain with Google), but that can easily be solved by not having the domain admin accounts use the domain they're hosted on.

fastest963 2y ago

We take the OAuth2 token and make a call to the People API [0] to get the Person resourceName. Not sure if this is more stable than "sub" but we completely ignore that. [0] https://developers.google.com/people/api/rest/v1/people/get https://developers.google.com/people/api/rest/v1/people/get

deathanatos 2y ago

> 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. I've had a staff SWE also claim to me that they generated colliding UUIDv4s, and a separate staff SWE who worked in GIS claim that circles only exist in map projections and they're always distorted, and that you cannot have a circle IRL, nor project it onto a projection. Neither's attention to quality, or rather, lack thereof, could cash those outlandish claims. There is a simple explanation here: Your staff SWE is wrong. `sub` is the claim you're looking for. Extraordinary claims require at least a trifling of proof. Or, what can be asserted without evidence can also be dismissed without evidence. And this alleges to be a security blog. As a writer with that target audience, you should know this is going to be the objection to the thesis that your reader will have, and you attempt to just handwave it away…?

j16sdiz 2y ago
> I've had a staff SWE also claim to me that they generated colliding UUIDv4s, UUIDv4 is random. Could be a bad PRNG, or just very very very bad luck. > and a separate staff SWE who worked in GIS claim that circles only exist in map projections and they're always distorted, and that you cannot have a circle IRL, nor project it onto a projection. It is insanely difficult to project circles. Most of time we just pretend it never exist.
- deathanatos 2y ago
  > or just very very very bad luck. You're underestimating the odds. The odds aren't "bad luck", the odds are "statistical impossibility". Literally any other explanation holds with orders of magnitude higher certainty. > It is insanely difficult to project circles. Most of time we just pretend it never exist. Open Google maps, find the equator. That's a circle, rendered on a projection. (But far from the only example possible.) (And lest I get more objections, a perfectly spherical earth was also an assumption of this assertion that circles don't exist. My coworker attempted to draw/show a circle onto an actual sphere we fortuitously had handy, and no dice.) (Note the other way exists too: a projection can have a circle rendered on it, though it wouldn't be a circle on an actual sphere.)
2y ago

necovek 2y ago

Assuming most of the problem is that federated services only rely on email address from OidC login, I wonder if Google could start offering user+unique-workspace-id@company.domain as the email address for any new workspace/user/federated login? Obviously, Google needs to control "unique-workspace-id". Does not solve it for existing customers and any federated service they logged into, though if included alongside the simple email, federated services could gradually move to it and announce once they are "ready" so workspace admins can configure them to start accepting only new, safe email addresses.

lovasoa 2y ago

Does anyone here know more about the unreliability of Google's sub claim? I am using it, and have never had issues with it, but this post seems to just dismiss it without more details. When does Google change the subject of a token for a given user account?

xinayder 2y ago

I fail to see how this is Google's problem and as much as it pains me to say this, I agree with Google. I believe it is more the downstream providers fault for not terminating inactive accounts, and the failed startup's for not properly deleting their Google accounts. Google can mitigate this as the author mentioned, but this is not their responsibility. They shouldn't be held liable because failed startups were stupid to not delete their data.

jimjonah 2y ago

It sounds like there’s a bug with the “sub” field. The author is stating that they can’t use it as a unique identifier for the user. Isn’t that the root of the problem? A new domain owner could try to reuse email addresses, but since the domain is now in a new workspace the sub should be different and downstream services shouldn’t second guess that. Am I wrong about this?

moi2388 2y ago

For the people not understanding the security risk, or how this would be something Google needs to solve, have a look at the claims of Microsoft Id token claims, and how their use of multiple guid claims completely eliminates this problem: https://learn.microsoft.com/en-us/entra/identity-platform/id-token-claims-reference https://learn.microsoft.com/en-us/entra/identity-platform/id...