5 ms·

The problem is that you don't have control over what third parties are doing here. You may have control over the policies associated with tokens issued by your

by mjg59 5y ago

The problem is that you don't have control over what third parties are doing here. You may have control over the policies associated with tokens issued by your identity provider, but how do you audit the policies that third party services are applying to their tokens?

xnorswap 5y ago
I don't understand the argument here, if you're not issuing the tokens then they're not your responsibility. Can you give a more fleshed out example, why should you audit third party services?
- 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.
iso1631 5y ago
So I have a service using openid and I use google to authenticate the person logging in. I do that, then that's done. Now I could simply issue a session cookie, or a permament cookie, to the client so we never have to use google again. Or I could make it so that cookie lasts 10 minutes before reauthentication. I can use a refresh token which means they don't need to reauthenticate but if google expires the connection (disabled user etc), I expire mine. Either way, that's my decision as the person running my site, and it's the clients decision as the person running the client to decide whether to send the blob, or to share that blob with other clients. The only information I know is that somebody authenticated with google at a specific time and I had proof of that, I have no control over what happens to that blob. Google has nothing to do with what I or the client do with the information. You're right that I can't audit the third party (google, microsoft, etc), but I don't pretend I can. Google could simply change their password checking to "if (true)", that's google's business. If I'm worried about the third party authenticator then I shouldn't use it, and I should roll my own. (There was an early Tom Scott video imagining a world where google just says "yes" to passwords[0]) I have an internal read-only blog site using our corporate openid service to ensure that someone accesses the site. Once they authenticate, I allow them access for 30 days before forcing a reauthentication, because it's low risk. OK if they log in from a compromised machine than a hacker gets to read some internal information, its very low risk. I've also got a site where you can make major changes. You have to reauthenticate far more frequently to make those changes (every 30 minutes). It's a matter of risk. [0] https://www.youtube.com/watch?v=y4GB_NDU43Q https://www.youtube.com/watch?v=y4GB_NDU43Q
- mjg59 5y ago
  I, as the company paying for your service, have no direct ability to influence the policy that you apply to the tokens you issue. If you start issuing tokens that are good for decades, I have no trivial mechanism to detect that.
  - iso1631 5y ago
    Ask before you spend the money, stick it in the contract. If you don't like the answer don't sign the contract.

by mjg59 5y ago

xnorswap 5y ago

I don't understand the argument here, if you're not issuing the tokens then they're not your responsibility. Can you give a more fleshed out example, why should you audit third party services?

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.

iso1631 5y ago

So I have a service using openid and I use google to authenticate the person logging in. I do that, then that's done. Now I could simply issue a session cookie, or a permament cookie, to the client so we never have to use google again. Or I could make it so that cookie lasts 10 minutes before reauthentication. I can use a refresh token which means they don't need to reauthenticate but if google expires the connection (disabled user etc), I expire mine. Either way, that's my decision as the person running my site, and it's the clients decision as the person running the client to decide whether to send the blob, or to share that blob with other clients. The only information I know is that somebody authenticated with google at a specific time and I had proof of that, I have no control over what happens to that blob. Google has nothing to do with what I or the client do with the information. You're right that I can't audit the third party (google, microsoft, etc), but I don't pretend I can. Google could simply change their password checking to "if (true)", that's google's business. If I'm worried about the third party authenticator then I shouldn't use it, and I should roll my own. (There was an early Tom Scott video imagining a world where google just says "yes" to passwords[0]) I have an internal read-only blog site using our corporate openid service to ensure that someone accesses the site. Once they authenticate, I allow them access for 30 days before forcing a reauthentication, because it's low risk. OK if they log in from a compromised machine than a hacker gets to read some internal information, its very low risk. I've also got a site where you can make major changes. You have to reauthenticate far more frequently to make those changes (every 30 minutes). It's a matter of risk. [0] https://www.youtube.com/watch?v=y4GB_NDU43Q https://www.youtube.com/watch?v=y4GB_NDU43Q

mjg59 5y ago
I, as the company paying for your service, have no direct ability to influence the policy that you apply to the tokens you issue. If you start issuing tokens that are good for decades, I have no trivial mechanism to detect that.
- iso1631 5y ago
  Ask before you spend the money, stick it in the contract. If you don't like the answer don't sign the contract.