4 ms·

In server-to-server, the client is considered trustworthy—no third party is supposed to be able to get the source or inspect memory, and OAuth secret can be a t

In server-to-server, the client is considered trustworthy—no third party is supposed to be able to get the source or inspect memory, and OAuth secret can be a thing. But if you are, say, GitHub, how can you prove that GitHub Desktop instance trying to auth on behalf of the user is genuinely GitHub Desktop and not some malicious impostor, who previously extracted all the tokens from the original app and now is trying to get access to user’s repos?

dwaite 5y ago
How do you know that the Github desktop instance hasn't been compromised by eval()'ing some third party code, and is using the tokens the client already has? For that matter - what is the difference between a token in a piece of code on the desktop and code on a server to third-party attackers, other than the server is a much more attractive central location to attack so that you compromise everyone at once? A lot of effort is spent on trying to identify a client as trustworthy and in preventing exfiltration of tokens, but generally a good portion of the security budget should instead be spent on how to mitigate risks. A trusted system is one where you have accepted you are fubar if it is compromised. It is equally important to evaluate the trustworthiness of systems as it is to reduce the need to have trustworthy systems in the first place. That unfortunately means actually having security considerations as part of the overall system design, and not just firewalling systems with policy at the end. You can reduce overall risk at authorization servers by not supporting dynamic registration, or limiting such registrations to a small set of acceptable scopes and claims. You also want to make sure you can revoke compromised tokens in a reasonable amount of time, such as due to device compromise, client compromise (or identified malicious client), or user account compromise. That usually can be done with just refresh tokens with appropriately short lifetimes for many systems. But the underlying protected resources still need to be designed to reduce risk as well. They should not expose functionality which clients do not need, both by having limited scopes and simply not exposing functionality publicly via API at all. They should also minimize destructive actions - actions should be reversible, such as restoring a deleted record or cancelling a pending order. Additionally, you'll want to invest in phishing-resistant authentication as much as possible. That means sticking to best practices and going to an external agent (browser) when authenticating, and ideally adopting something like WebAuthn or mutual TLS or Kerberos. Determining trustworthy clients or limiting API access does no good if the user hands a malicious piece of software their actual system credentials.
- goblin89 5y ago
  > what is the difference between a token in a piece of code on the desktop and code on a server to third-party attackers, other than the server is a much more attractive central location to attack so that you compromise everyone at once? Unlike servers, end-user machines are supposed to execute third-party code not vetted by the developer, which makes for a pretty stark difference as to attack surface. > A lot of effort is spent on trying to identify a client as trustworthy and in preventing exfiltration of tokens Read linked documents. The relevant RFC explicitly states that no token bundled together with a native app can be considered “secret” and preventing its extraction is not a viable security measure.

dwaite 5y ago

How do you know that the Github desktop instance hasn't been compromised by eval()'ing some third party code, and is using the tokens the client already has? For that matter - what is the difference between a token in a piece of code on the desktop and code on a server to third-party attackers, other than the server is a much more attractive central location to attack so that you compromise everyone at once? A lot of effort is spent on trying to identify a client as trustworthy and in preventing exfiltration of tokens, but generally a good portion of the security budget should instead be spent on how to mitigate risks. A trusted system is one where you have accepted you are fubar if it is compromised. It is equally important to evaluate the trustworthiness of systems as it is to reduce the need to have trustworthy systems in the first place. That unfortunately means actually having security considerations as part of the overall system design, and not just firewalling systems with policy at the end. You can reduce overall risk at authorization servers by not supporting dynamic registration, or limiting such registrations to a small set of acceptable scopes and claims. You also want to make sure you can revoke compromised tokens in a reasonable amount of time, such as due to device compromise, client compromise (or identified malicious client), or user account compromise. That usually can be done with just refresh tokens with appropriately short lifetimes for many systems. But the underlying protected resources still need to be designed to reduce risk as well. They should not expose functionality which clients do not need, both by having limited scopes and simply not exposing functionality publicly via API at all. They should also minimize destructive actions - actions should be reversible, such as restoring a deleted record or cancelling a pending order. Additionally, you'll want to invest in phishing-resistant authentication as much as possible. That means sticking to best practices and going to an external agent (browser) when authenticating, and ideally adopting something like WebAuthn or mutual TLS or Kerberos. Determining trustworthy clients or limiting API access does no good if the user hands a malicious piece of software their actual system credentials.

goblin89 5y ago
> what is the difference between a token in a piece of code on the desktop and code on a server to third-party attackers, other than the server is a much more attractive central location to attack so that you compromise everyone at once? Unlike servers, end-user machines are supposed to execute third-party code not vetted by the developer, which makes for a pretty stark difference as to attack surface. > A lot of effort is spent on trying to identify a client as trustworthy and in preventing exfiltration of tokens Read linked documents. The relevant RFC explicitly states that no token bundled together with a native app can be considered “secret” and preventing its extraction is not a viable security measure.