5 ms·

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

by 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
Sure, but DankStartup failed and doesn’t exist anymore. If I am just a lowly employee, I can’t force the failed startup owners to properly shutdown, and now my payroll information is available to hackers. What is my remedy?
- DrillShopper 2y ago
  In a rational world the remedy would be to sue Google for exposing your payroll information.
  - dragonwriter 2y ago
    Google is neither the party holding the payroll information nor the party that chose to make it available on terms that are insecure against loss of control of the domain, why would it be rational for them to be liable?
    - DrillShopper 2y ago
      Because they're running the faulty auth
- patmcc 2y ago
  Probably sue the failed startup owners for negligence? If DankStartup left all your HR files lying around in their office and the guy who bought it five years later found them, well, DankStartup should have shredded them. It'd sure be nice if the cleaners shredded them for you, but I wouldn't count on it (nor make them liable).
  - dragonwriter 2y ago
    > Probably sue the failed startup owners for negligence The owners generally aren't liable (assuming or corp or LLC), and if the company would have been liable, that liability probably died with the firm.
tsimionescu 2y ago
It's a different bob@DankStartup.com, and in fact a completely different DankStartup.com. Google shouldn't conflate the two. There are exactly 0 situations where the current behavior is useful. There is no reason whatsoever to have the exact same auth info for two Google accounts that happen to have the same domain.
- freedomben 2y ago
  Whoever has access to the inbox and account for bob@DankStartup.com is bob@DankStartup.com. If Google was being asked if the SSN for bob is 123-45-6789 and they were saying yes, then I would agree that's an issue, but all Google is saying is "this person can authenticate to our services as bob@DankStartup.com" and that is true.
  - tsimionescu 2y ago
    But the new owner does not have access to the inbox or any other account info of the old bob@DankStartup.com. They're completely separate accounts, with the same email address. Plus, Google already recognizes that fact, by setting a different value in the "sub" field of the claim it returns (though per the article, it seems that may not work properly). And legal relations just don't work this way. A person is who they are, and it is that person who has legal access to whatever data was stored in their Slack. Another person who happens to have the same email some time later doesn't have any right whatsoever to that same data. OAuth exists to help secure this type of legal relation, not to establish a completely fictitious identity.
    - ForHackernews 2y ago
      > Google already recognizes that fact, by setting a different value in the "sub" field of the claim it returns Then Google is doing the right thing. It's incumbent on the relying party to enforce its own authorization policies based on the information the authorization server provides. Google says, "here's bob@example.net <id=n49d0x>", oh now "here's bob@example.net <id=pv82x1d>" Google can't save consumers from their own negligence.
    - 2y ago
Salgat 2y ago
Login credentials are more than just the email used, and should not be conflated with identity. To be honest I'm surprised google isn't using a uuid tied to the account for the identity given to others, especially since internally google knows and treats it as a separate account that just happens to have the same e-mail. The e-mail should only be used as metadata for contact info.
- jsnell 2y ago
  > To be honest I'm surprised google isn't using a uuid tied to the account for the identity given to others But they are providing a unique, stable, never reused identifier tied to the account, as has been mentioned a number of times in this thread. It's the "sub" field[0], whose entire purpose is to be the unique identifier for tying the IDP's data to the RP's data. What they're not doing is to provide that unique id in the "email" field, because the purpose of the email field is to contain the email address. The documentation even specifically tells not to use it as the primary identifier. > The e-mail should only be used as metadata for contact info Indeed. But that's up to the relying party. The only way to prevent them from checking the wrong field would be to not provide them the email address at all, even when they're explicitly requesting it. [0] https://developers.google.com/identity/openid-connect/openid-connect#an-id-tokens-payload https://developers.google.com/identity/openid-connect/openid...

by patmcc 2y ago

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

Sure, but DankStartup failed and doesn’t exist anymore. If I am just a lowly employee, I can’t force the failed startup owners to properly shutdown, and now my payroll information is available to hackers. What is my remedy?

DrillShopper 2y ago
In a rational world the remedy would be to sue Google for exposing your payroll information.
- dragonwriter 2y ago
  Google is neither the party holding the payroll information nor the party that chose to make it available on terms that are insecure against loss of control of the domain, why would it be rational for them to be liable?
  - DrillShopper 2y ago
    Because they're running the faulty auth
patmcc 2y ago
Probably sue the failed startup owners for negligence? If DankStartup left all your HR files lying around in their office and the guy who bought it five years later found them, well, DankStartup should have shredded them. It'd sure be nice if the cleaners shredded them for you, but I wouldn't count on it (nor make them liable).
- dragonwriter 2y ago
  > Probably sue the failed startup owners for negligence The owners generally aren't liable (assuming or corp or LLC), and if the company would have been liable, that liability probably died with the firm.

tsimionescu 2y ago

It's a different bob@DankStartup.com, and in fact a completely different DankStartup.com. Google shouldn't conflate the two. There are exactly 0 situations where the current behavior is useful. There is no reason whatsoever to have the exact same auth info for two Google accounts that happen to have the same domain.

freedomben 2y ago
Whoever has access to the inbox and account for bob@DankStartup.com is bob@DankStartup.com. If Google was being asked if the SSN for bob is 123-45-6789 and they were saying yes, then I would agree that's an issue, but all Google is saying is "this person can authenticate to our services as bob@DankStartup.com" and that is true.
- tsimionescu 2y ago
  But the new owner does not have access to the inbox or any other account info of the old bob@DankStartup.com. They're completely separate accounts, with the same email address. Plus, Google already recognizes that fact, by setting a different value in the "sub" field of the claim it returns (though per the article, it seems that may not work properly). And legal relations just don't work this way. A person is who they are, and it is that person who has legal access to whatever data was stored in their Slack. Another person who happens to have the same email some time later doesn't have any right whatsoever to that same data. OAuth exists to help secure this type of legal relation, not to establish a completely fictitious identity.
  - ForHackernews 2y ago
    > Google already recognizes that fact, by setting a different value in the "sub" field of the claim it returns Then Google is doing the right thing. It's incumbent on the relying party to enforce its own authorization policies based on the information the authorization server provides. Google says, "here's bob@example.net <id=n49d0x>", oh now "here's bob@example.net <id=pv82x1d>" Google can't save consumers from their own negligence.
  - 2y ago

Salgat 2y ago

Login credentials are more than just the email used, and should not be conflated with identity. To be honest I'm surprised google isn't using a uuid tied to the account for the identity given to others, especially since internally google knows and treats it as a separate account that just happens to have the same e-mail. The e-mail should only be used as metadata for contact info.

jsnell 2y ago
> To be honest I'm surprised google isn't using a uuid tied to the account for the identity given to others But they are providing a unique, stable, never reused identifier tied to the account, as has been mentioned a number of times in this thread. It's the "sub" field[0], whose entire purpose is to be the unique identifier for tying the IDP's data to the RP's data. What they're not doing is to provide that unique id in the "email" field, because the purpose of the email field is to contain the email address. The documentation even specifically tells not to use it as the primary identifier. > The e-mail should only be used as metadata for contact info Indeed. But that's up to the relying party. The only way to prevent them from checking the wrong field would be to not provide them the email address at all, even when they're explicitly requesting it. [0] https://developers.google.com/identity/openid-connect/openid-connect#an-id-tokens-payload https://developers.google.com/identity/openid-connect/openid...