8 ms·

Well, think about it this way: 1. I create DankStartup and my company uses Google workspaces and Google auth for a bunch of stuff, like payroll. 2. DankStartu

Well, think about it this way: 1. I create DankStartup and my company uses Google workspaces and Google auth for a bunch of stuff, like payroll. 2. DankStartup goes under and we close our Google accounts/let our domain lapse. 3. Someone else buys DankStartup.com, sets up a Google workspace, and attempts Google auth to log into stuff, and it works. The problem is that the original DankStartup has a Google account that they create in #1, and Google goes around telling other sites (via Auth) "this is user X from company Y". 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 therefore the same people as far as they're concerned and is asserting that to other companies. They are (or were) refusing to provide any indication to those other companies that these are not, in fact, the same people, so those other companies aren't even capable of doing their due diligence of extra validation if they want to. It's similar to looking at a driver's license and just matching the name rather than the actual ID number; it's possible for someone else to have the same name as you, and identity documents have unique identifiers for specifically that reason.

PKop 2y ago
Yes but he's saying the data on 3rd-party websites should be deleted by the failed startup when they shutdown not just left to sit there.
- PeterFBell 2y ago
  He's right, but having failed a number of times, after you've put all your savings into the business, fired all your team, notified and disappointed all of your investors and customers, helped your team find new gigs, filed all the dissolution paperwork, handled all the taxes, disposed responsibly of all of the assets and you now find yourself out of work and often out of cash, occasionally you'll forget to jump through all the hoops to close down all of the SaaS accounts before you stop paying the bill personally to host the email accounts. Of course perfect world you shut down earlier and in a more orderly fashion, but there are so many cases of companies almost failing and then not, it's hard to shutter a company when there is a chance you may go out of business - especially when you feel you're getting close to another raise or becoming default alive :(
  - deleted 2y ago
    [deleted]
- scarface_74 2y ago
  There are some 3rd party accounts that can be accessed via your SSO or via your personal credentials once you leave. The main ones I can think of is your brokerage account containing your 401K and vested RSUs and your payroll provider like ADP and Paylocity. You still need to have access to past paystubs and end of year tax documents.
  - anon84873628 2y ago
    SSO should stop working when the IdP org is disabled/deleted. IdPs should not allow the org to be resurrected based solely on domain ownership alone. And if a new org is created with the same domain, the SP will need to be reconfigured with new OAuth client creds, and should be relying only on the `sub` claim anyway. Any accounts you need after leaving a company should be tied to your personal email.
    - scarface_74 2y ago
      My brokerage account could be accessed by both. I agree that is how it should work. But my brokerage account provider is never told to disable access via my IdP. It’s up to my former IdP to not do something stupid like giving someone else my old email address.
      - necovek 2y ago
        It's not IdP's responsibility to "fix" the internet. Just like someone can buy a home and will get mail targeting a previous owner, the same happens with domain names and emails. Domains are, however, much cheaper and more abundant, so it happens more often.
- mikeryan 2y ago
  There’s an interesting question on service providers responsiblity who use Oauth for primary auth. Should they reset all access to a company account if a domain transfers or becomes publicly available?
rahkiin 2y ago
Any domain takeover allows email takeover which allows you to send password reset emails for former employees. Does not matter if it is with oauth or not
- mtkd 2y ago
  And many vendors will send "restart your service today for $x" for months afterwards so data not deleted Some SaaS ecommerce platforms and email marketing services will likely give a restarted domain entire customer databases ...
  - rahkiin 2y ago
    There should be some service for permanently destroying a domain with a single prepaid cost. Somehow preventing bankruptcy laws from getting the domain. Pay X$ up front, then Y$ per month to keep active. Once you cannot pay, it gets blocked forever (paid for by the up front cost). Owned by your service provider so not part of your firesale
    - ocdtrekkie 2y ago
      What happens when your service provider that owns your domain collapses?
- anon84873628 2y ago
  Those password resets should have some sort of MFA step.
  - jpc0 2y ago
    Sue lost hee phone, she used KeePass for everything and didn't back it up. She get some support from IT, what do they do to solve Sue's problem? They reset her password and 2FA and have her redo them. She probably gets a lecture about backups or she spurns a brand new company policy that "Everyone should now use LastPass and nothing else is supported". If they as administrators cannot do that, Sue has now lost significant business data, there will be a dexent amount of work stopped to get Sue onboarded again and this is a significant issue. An auditable log that X reset Sue's password ane 2FA codes at x time while at x location with biometric authentication is pretty secure. If X also ca nnot touch those logs the next strawman falls apart.
arnarbi 2y ago
> They are (or were) refusing to provide any indication to those other companies that these are not, in fact, the same people That is not quite true, the sub field will be different.
- Ninn 2y ago
  But authors does imply that sub will also change in place for users in step #1, without the workspace beeing recreated. And as such the sub is not usable as a general identifier for the user resource differentiation.
  - anon84873628 2y ago
    The sub property appearing to change for the same email address is a valid scenario. SPs failing to respect that scenario because they don't understand it, or because it's not what some of their users want, is not a valid excuse. 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... To me it is reasonable that orgs may want to eventually reuse an email address on a different user account. That's a feature decision made by the IdP so SPs need to respect it. I believe other IdPs like Okta and Entra have equivalent features too.
    - Ninn 2y ago
      > To me it is reasonable that orgs may want to eventually reuse an email address on a different user account. That's a feature decision made by the IdP so SPs need to respect it I think everyone, including the authors hopefully agrees with that logic and sentiment. And that would be the literal point of the sub claim after all! But the implication in the article is still, as i read it, that it changes in place in practice, and not in the case of re-creating the user under the same workspace. But i obviously do not have the background to clarify!
- tsimionescu 2y ago
  This is not necessarily useful. The sub field only indicates that this is a different user, which maybe protects the private info of the old user. However, a big part of OIDC integration is to automatically allow any valid user registered with the IdP to automatically have access to the corporate account, and to any company-wide resources, which can still include very sensitive information.
anon84873628 2y ago
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 happened... I assume not, since if it were the case we'd be talking about direct access to the Google account data rather than only linked SP accounts. The second is when an SP doesn't properly use the `sub` claim as a unique identifier. It sounds like some products don't understand this requirement and why it "seems to change 0.04%" of the time. I do agree that a unique identifier for the org itself would be a good addition to the token. 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. Presumably attacker can login to the SP admin account using just email based password recovery, then reconfigure the OAuth integration with new secrets. In that case the SP is failing to do MFA on the email login. Would love to hear if I'm missing something.
- tsimionescu 2y ago
  > 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 user that Google's public OAuth IdP says is a valid user in the example.com domain. Slack doesn't have to do any MFA for these accounts, they trust Google did that already. Now, you may not be able to access the Slack org admin account in this way, say to add/remove users or delete the org. But you can access all of the other information that any random employee in the org could access back when it was setup, including a list of all other users in the org.
  - anon84873628 2y ago
    Ah, right, Slack can have their own public oath client which is used for the code grant. 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.
stackghost 2y ago
>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 therefore the same people as far as they're concerned and is asserting that to other companies. Yep I understand the mechanism by which this gets abused; I think we just disagree on the implications. I don't work for Google but it seems from the outside that they're treating the OIDC subject claim as referencing the domain attached to the workspace account, or something similar. I've seen implementations where the `sub` claim is more granular, so to me that indicates the field is underspecified. Given all that, I suppose TFAuthor's proposed solution is a good way forward. I still think classifying this as an OAuth vulnerability isn't correct.
- radlad 2y ago
  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 and internal applications" here: https://support.google.com/cloud/answer/6158849?hl=en#zippy=%2Cpublic-and-internal-applications https://support.google.com/cloud/answer/6158849?hl=en#zippy=... Some applications (e.g. Tailscale) take advantage of the public Google OAuth API to provide private internal corporate accounts. A common misconfiguration here is to use the domain portion of the "email" attribute - this can be spoofed by Google Workspace admins. That's not what's happening here. Instead, Google instructs you to look at the "hd" parameter, specific to Google, to determine the Google Workspace a given user belongs to for security purposes. This field cannot be overridden by Google Workspace admins. The trust breaks down when the domain changes hands, a new Google Workspace account is opened, but the old "hd" value is reused. You can read more about "hd" here: https://developers.google.com/identity/openid-connect/openid-connect https://developers.google.com/identity/openid-connect/openid... (find the table and read the descriptions for both "email" and "hd".) You can avoid this issue by using a custom Google OIDC IdP configured for internal access only in your applications, rather than using a pre-configured public Google OIDC IdP (be very careful you mark it internal!) A new domain owner would not be able to retrieve the secret key you previously generated.
patmcc 2y ago
>>>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?
- grepfru_it 2y ago
  Part of my company dissolution process is to renew the domain name for 10 years to prevent exactly this
  - jedberg 2y ago
    Is the hope that this sort of attack is just less useful in 10 years? What happens after 10 years?
    - stackghost 2y ago
      Presumably after 10 years of failing to collect on their invoices, Microsoft would have killed your O365 account, so there's one fewer SaaS account left to log into.
    - paulddraper 2y ago
      Yes
    - grepfru_it 2y ago
      Common sense would dictat that you have sunset your business by this time.
  - mansilladev 2y ago
    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.
- cortesoft 2y ago
otabdeveloper4 2y ago
I don't see the problem here. We've already settled on DNS being the auhoritative authentication key for everything. If you bought the domain then you've bought the corporate identity. It's working as designed.
- dinoqqq 2y ago
  The flaw is the fact that companies go bankrupt and their data should die with them. In case of bankruptcy it might be impossible to hold on to your DNS and therefore risking old company data leaking.
  - echoangle 2y ago
    Can’t you just actively delete the company accounts when closing down?

PKop 2y ago

Yes but he's saying the data on 3rd-party websites should be deleted by the failed startup when they shutdown not just left to sit there.

PeterFBell 2y ago
He's right, but having failed a number of times, after you've put all your savings into the business, fired all your team, notified and disappointed all of your investors and customers, helped your team find new gigs, filed all the dissolution paperwork, handled all the taxes, disposed responsibly of all of the assets and you now find yourself out of work and often out of cash, occasionally you'll forget to jump through all the hoops to close down all of the SaaS accounts before you stop paying the bill personally to host the email accounts. Of course perfect world you shut down earlier and in a more orderly fashion, but there are so many cases of companies almost failing and then not, it's hard to shutter a company when there is a chance you may go out of business - especially when you feel you're getting close to another raise or becoming default alive :(
- deleted 2y ago
  [deleted]
scarface_74 2y ago
There are some 3rd party accounts that can be accessed via your SSO or via your personal credentials once you leave. The main ones I can think of is your brokerage account containing your 401K and vested RSUs and your payroll provider like ADP and Paylocity. You still need to have access to past paystubs and end of year tax documents.
- anon84873628 2y ago
  SSO should stop working when the IdP org is disabled/deleted. IdPs should not allow the org to be resurrected based solely on domain ownership alone. And if a new org is created with the same domain, the SP will need to be reconfigured with new OAuth client creds, and should be relying only on the `sub` claim anyway. Any accounts you need after leaving a company should be tied to your personal email.
  - scarface_74 2y ago
    My brokerage account could be accessed by both. I agree that is how it should work. But my brokerage account provider is never told to disable access via my IdP. It’s up to my former IdP to not do something stupid like giving someone else my old email address.
    - necovek 2y ago
      It's not IdP's responsibility to "fix" the internet. Just like someone can buy a home and will get mail targeting a previous owner, the same happens with domain names and emails. Domains are, however, much cheaper and more abundant, so it happens more often.
mikeryan 2y ago
There’s an interesting question on service providers responsiblity who use Oauth for primary auth. Should they reset all access to a company account if a domain transfers or becomes publicly available?

rahkiin 2y ago

Any domain takeover allows email takeover which allows you to send password reset emails for former employees. Does not matter if it is with oauth or not

mtkd 2y ago
And many vendors will send "restart your service today for $x" for months afterwards so data not deleted Some SaaS ecommerce platforms and email marketing services will likely give a restarted domain entire customer databases ...
- rahkiin 2y ago
  There should be some service for permanently destroying a domain with a single prepaid cost. Somehow preventing bankruptcy laws from getting the domain. Pay X$ up front, then Y$ per month to keep active. Once you cannot pay, it gets blocked forever (paid for by the up front cost). Owned by your service provider so not part of your firesale
  - ocdtrekkie 2y ago
    What happens when your service provider that owns your domain collapses?
anon84873628 2y ago
Those password resets should have some sort of MFA step.
- jpc0 2y ago
  Sue lost hee phone, she used KeePass for everything and didn't back it up. She get some support from IT, what do they do to solve Sue's problem? They reset her password and 2FA and have her redo them. She probably gets a lecture about backups or she spurns a brand new company policy that "Everyone should now use LastPass and nothing else is supported". If they as administrators cannot do that, Sue has now lost significant business data, there will be a dexent amount of work stopped to get Sue onboarded again and this is a significant issue. An auditable log that X reset Sue's password ane 2FA codes at x time while at x location with biometric authentication is pretty secure. If X also ca nnot touch those logs the next strawman falls apart.

arnarbi 2y ago

> They are (or were) refusing to provide any indication to those other companies that these are not, in fact, the same people That is not quite true, the sub field will be different.

Ninn 2y ago
But authors does imply that sub will also change in place for users in step #1, without the workspace beeing recreated. And as such the sub is not usable as a general identifier for the user resource differentiation.
- anon84873628 2y ago
  The sub property appearing to change for the same email address is a valid scenario. SPs failing to respect that scenario because they don't understand it, or because it's not what some of their users want, is not a valid excuse. 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... To me it is reasonable that orgs may want to eventually reuse an email address on a different user account. That's a feature decision made by the IdP so SPs need to respect it. I believe other IdPs like Okta and Entra have equivalent features too.
  - Ninn 2y ago
    > To me it is reasonable that orgs may want to eventually reuse an email address on a different user account. That's a feature decision made by the IdP so SPs need to respect it I think everyone, including the authors hopefully agrees with that logic and sentiment. And that would be the literal point of the sub claim after all! But the implication in the article is still, as i read it, that it changes in place in practice, and not in the case of re-creating the user under the same workspace. But i obviously do not have the background to clarify!
tsimionescu 2y ago
This is not necessarily useful. The sub field only indicates that this is a different user, which maybe protects the private info of the old user. However, a big part of OIDC integration is to automatically allow any valid user registered with the IdP to automatically have access to the corporate account, and to any company-wide resources, which can still include very sensitive information.

anon84873628 2y ago

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 happened... I assume not, since if it were the case we'd be talking about direct access to the Google account data rather than only linked SP accounts. The second is when an SP doesn't properly use the `sub` claim as a unique identifier. It sounds like some products don't understand this requirement and why it "seems to change 0.04%" of the time. I do agree that a unique identifier for the org itself would be a good addition to the token. 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. Presumably attacker can login to the SP admin account using just email based password recovery, then reconfigure the OAuth integration with new secrets. In that case the SP is failing to do MFA on the email login. Would love to hear if I'm missing something.

tsimionescu 2y ago
> 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 user that Google's public OAuth IdP says is a valid user in the example.com domain. Slack doesn't have to do any MFA for these accounts, they trust Google did that already. Now, you may not be able to access the Slack org admin account in this way, say to add/remove users or delete the org. But you can access all of the other information that any random employee in the org could access back when it was setup, including a list of all other users in the org.
- anon84873628 2y ago
  Ah, right, Slack can have their own public oath client which is used for the code grant. 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.

stackghost 2y ago

>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 therefore the same people as far as they're concerned and is asserting that to other companies. Yep I understand the mechanism by which this gets abused; I think we just disagree on the implications. I don't work for Google but it seems from the outside that they're treating the OIDC subject claim as referencing the domain attached to the workspace account, or something similar. I've seen implementations where the `sub` claim is more granular, so to me that indicates the field is underspecified. Given all that, I suppose TFAuthor's proposed solution is a good way forward. I still think classifying this as an OAuth vulnerability isn't correct.

radlad 2y ago
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 and internal applications" here: https://support.google.com/cloud/answer/6158849?hl=en#zippy=%2Cpublic-and-internal-applications https://support.google.com/cloud/answer/6158849?hl=en#zippy=... Some applications (e.g. Tailscale) take advantage of the public Google OAuth API to provide private internal corporate accounts. A common misconfiguration here is to use the domain portion of the "email" attribute - this can be spoofed by Google Workspace admins. That's not what's happening here. Instead, Google instructs you to look at the "hd" parameter, specific to Google, to determine the Google Workspace a given user belongs to for security purposes. This field cannot be overridden by Google Workspace admins. The trust breaks down when the domain changes hands, a new Google Workspace account is opened, but the old "hd" value is reused. You can read more about "hd" here: https://developers.google.com/identity/openid-connect/openid-connect https://developers.google.com/identity/openid-connect/openid... (find the table and read the descriptions for both "email" and "hd".) You can avoid this issue by using a custom Google OIDC IdP configured for internal access only in your applications, rather than using a pre-configured public Google OIDC IdP (be very careful you mark it internal!) A new domain owner would not be able to retrieve the secret key you previously generated.

patmcc 2y ago

>>>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?

grepfru_it 2y ago
Part of my company dissolution process is to renew the domain name for 10 years to prevent exactly this
- jedberg 2y ago
  Is the hope that this sort of attack is just less useful in 10 years? What happens after 10 years?
  - stackghost 2y ago
    Presumably after 10 years of failing to collect on their invoices, Microsoft would have killed your O365 account, so there's one fewer SaaS account left to log into.
  - paulddraper 2y ago
    Yes
  - grepfru_it 2y ago
    Common sense would dictat that you have sunset your business by this time.
- mansilladev 2y ago
  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.
cortesoft 2y ago

otabdeveloper4 2y ago

I don't see the problem here. We've already settled on DNS being the auhoritative authentication key for everything. If you bought the domain then you've bought the corporate identity. It's working as designed.

dinoqqq 2y ago
The flaw is the fact that companies go bankrupt and their data should die with them. In case of bankruptcy it might be impossible to hold on to your DNS and therefore risking old company data leaking.
- echoangle 2y ago
  Can’t you just actively delete the company accounts when closing down?