4 ms·

And replacing it with auth code flow fixes that? I'll go along with auth code flow to fix Safari (now everyone) breaking cookies, but the security aspect of PKC

by hirsin 6y ago

And replacing it with auth code flow fixes that? I'll go along with auth code flow to fix Safari (now everyone) breaking cookies, but the security aspect of PKCE always smelled to me.

tptacek 6y ago
In the standard auth code flow, the authorizing application (I forget the OAuth terms for it, but "TweetLater" or whatever) shares a secret with Twitter, independent of the secret (your authentication credentials) you share with Twitter. The code you, a user, get --- that's fed through your browser --- is in a sense "locked" to "TweetLater". Part of the idea of the implicit flow is that it's for settings where you can't do that, or where it doesn't make sense (SPAs, for instance, where the secret the SPA would share with Twitter would be have to be embedded in the public Javascript code). PKCE is just a weaker version of that protection.
- hirsin 6y ago
  Thanks for taking a stab at it. I'm well aware of how the auth code flow works - I have yet to see a serious discussion though on how PKCE fixes the issues inherent in the implicit flow. Everything I've seen is "implicit bad, PKCE adds security to other flows, therefore PKCE fixes implicit grant problems". Which is of course non sensical, but great for memetic transmission.
  - tptacek 6y ago
    I guess I'm not clear on where you're not clear. PKCE adds a secret that the redeemer of the auth code returned from (say) Twitter needs to know to use the code. The big problem with implicit flow is the extent to which it exposes that code; PKCE makes it harder to use the code once exposed.
    - hirsin 6y ago
      As you yourself said - a problem with implicit flows is abuse of open redirects. It's a rare open redirect that is vulnerable to implicit that's not also vulnerable to PKCE protected auth code flow. This pattern is generally true across the board for implicit grant vulnerabilities. I was hoping you knew of known value-add versus what's usually seen (when anything is examined at all) - contrived scenarios where the attacker can only abuse minor parts of an open redirect or has JS execution but not the ability to make off-box calls, etc. The subtle browser interactions, as you call out, are the problem, not the one versus two legged nature of running session existence into tokens. (Of course, in auth code flow you now have RTs, so now you have N+1 problems...) It's more of a discussion for the standards groups I suppose.

by hirsin 6y ago

And replacing it with auth code flow fixes that? I'll go along with auth code flow to fix Safari (now everyone) breaking cookies, but the security aspect of PKCE always smelled to me.

tptacek 6y ago

In the standard auth code flow, the authorizing application (I forget the OAuth terms for it, but "TweetLater" or whatever) shares a secret with Twitter, independent of the secret (your authentication credentials) you share with Twitter. The code you, a user, get --- that's fed through your browser --- is in a sense "locked" to "TweetLater". Part of the idea of the implicit flow is that it's for settings where you can't do that, or where it doesn't make sense (SPAs, for instance, where the secret the SPA would share with Twitter would be have to be embedded in the public Javascript code). PKCE is just a weaker version of that protection.

hirsin 6y ago
Thanks for taking a stab at it. I'm well aware of how the auth code flow works - I have yet to see a serious discussion though on how PKCE fixes the issues inherent in the implicit flow. Everything I've seen is "implicit bad, PKCE adds security to other flows, therefore PKCE fixes implicit grant problems". Which is of course non sensical, but great for memetic transmission.
- tptacek 6y ago
  I guess I'm not clear on where you're not clear. PKCE adds a secret that the redeemer of the auth code returned from (say) Twitter needs to know to use the code. The big problem with implicit flow is the extent to which it exposes that code; PKCE makes it harder to use the code once exposed.
  - hirsin 6y ago
    As you yourself said - a problem with implicit flows is abuse of open redirects. It's a rare open redirect that is vulnerable to implicit that's not also vulnerable to PKCE protected auth code flow. This pattern is generally true across the board for implicit grant vulnerabilities. I was hoping you knew of known value-add versus what's usually seen (when anything is examined at all) - contrived scenarios where the attacker can only abuse minor parts of an open redirect or has JS execution but not the ability to make off-box calls, etc. The subtle browser interactions, as you call out, are the problem, not the one versus two legged nature of running session existence into tokens. (Of course, in auth code flow you now have RTs, so now you have N+1 problems...) It's more of a discussion for the standards groups I suppose.