4 ms·

Hypothetical: I have a Github Enterprise org. Users log in via my identity provider to gain access. Github then issues a long-lived oauth token to the Github De

by mjg59 5y ago

Hypothetical: I have a Github Enterprise org. Users log in via my identity provider to gain access. Github then issues a long-lived oauth token to the Github Desktop app. An attacker compromises a user's laptop and copies that oauth token. That attacker now has access to all my private repos until I notice and revoke it.

iso1631 5y ago
That's github's service, before choosing to use it you should look at these policies (who and how github enterprise trust tokens) and see if it matches your needs. If you were running the service, then the power to trust those tokens is with you.
- mjg59 5y ago
  You're a 5-person startup. How do you verify that all of Github's token issuance policies align with your needs?
  - iso1631 5y ago
    Don't. Run your own. It's a cost of business, you can either rely on the standard terms of your suppliers, or you can supply your own, it's far easier than the vast majority of industries. Git especially is a federated system that has no need for things like github.
    - mjg59 5y ago
      Or we could invent better solutions where we didn't need to depend on policies imposed by vendors? The value that Github provides isn't around their git hosting, it's all the integrated features. Reimplementing that isn't going to be trivial - there's a reason so many people use hosted Git rather than doing it themselves.
xnorswap 5y ago
So you're worried that a very short lived compromise of a SSI / federated auth layer can lead to long-lived compromises of everything it grants access to because a short time can be used to generate long-lived auth to third parties? That's a legitimate concern, any compromise of the SSI needs a complete refresh of anything it's touched, including refreshing all API keys, keyrings, etc. Hopefully as the ecosystem matures it'll be easier to en-masse mark an account as compromised and have that status propagate and trigger resets of affected credentials. A similar threat is insider threat, (probably actually a greater threat) where someone leaving a company could generate tokens which grant them access for long after they've gone. If reason about how that's typically managed (disabling their upstream accounts) that gives insight into how to deal with your initial concern, it should be managed in the same way.
- mjg59 5y ago
  No, I'm worried that if someone has temporary access to a machine that has one of these long-lived tokens, they may continue to have access to anything that that long-lived token grants access to.
  - xnorswap 5y ago
    But then there's no third party in that scenario, that's down to whoever was issuing those tokens and is part of securing their service.
    - mjg59 5y ago
      I control my laptops. I control the policy for my identity provider. The service that hosts my source code is a third party, and defines their own policy which may not match mine.

by mjg59 5y ago

iso1631 5y ago

That's github's service, before choosing to use it you should look at these policies (who and how github enterprise trust tokens) and see if it matches your needs. If you were running the service, then the power to trust those tokens is with you.

mjg59 5y ago
You're a 5-person startup. How do you verify that all of Github's token issuance policies align with your needs?
- iso1631 5y ago
  Don't. Run your own. It's a cost of business, you can either rely on the standard terms of your suppliers, or you can supply your own, it's far easier than the vast majority of industries. Git especially is a federated system that has no need for things like github.
  - mjg59 5y ago
    Or we could invent better solutions where we didn't need to depend on policies imposed by vendors? The value that Github provides isn't around their git hosting, it's all the integrated features. Reimplementing that isn't going to be trivial - there's a reason so many people use hosted Git rather than doing it themselves.

xnorswap 5y ago

So you're worried that a very short lived compromise of a SSI / federated auth layer can lead to long-lived compromises of everything it grants access to because a short time can be used to generate long-lived auth to third parties? That's a legitimate concern, any compromise of the SSI needs a complete refresh of anything it's touched, including refreshing all API keys, keyrings, etc. Hopefully as the ecosystem matures it'll be easier to en-masse mark an account as compromised and have that status propagate and trigger resets of affected credentials. A similar threat is insider threat, (probably actually a greater threat) where someone leaving a company could generate tokens which grant them access for long after they've gone. If reason about how that's typically managed (disabling their upstream accounts) that gives insight into how to deal with your initial concern, it should be managed in the same way.

mjg59 5y ago
No, I'm worried that if someone has temporary access to a machine that has one of these long-lived tokens, they may continue to have access to anything that that long-lived token grants access to.
- xnorswap 5y ago
  But then there's no third party in that scenario, that's down to whoever was issuing those tokens and is part of securing their service.
  - mjg59 5y ago
    I control my laptops. I control the policy for my identity provider. The service that hosts my source code is a third party, and defines their own policy which may not match mine.