CODEWITHSUNDEEP
oauth-2.0pkce
christiaantober
christiaantober

Reputation: 341

PKCE: Why bother to hash the code verifier?

From what I have read about PKCE, it is possible for malicious browser extensions to steal the authorization code from the browser history, but not the code verifier. If this is true, then why bother hashing the code verifier to make a code challenge?

Upvotes: 1

Views: 1157

Answers (2)

Nicholas Miller
Nicholas Miller

Reputation: 4400

a determined hacker can easily find the input using a lookup table.

I don't think this is the case. The code_verifier is composed of 43-128 characters from A-Z / a-z / 0-9 / - / . / _ / ~ (66 chars). So there are 66^43 - 66^128 possibilities.

For perspective, there are at least this many combinations:

1,739,358,998,350,143,493,317,779,844,390,084,859,341,773,852,978,927,698,440,263,217,183,107,995,140,096

Over a "25th-illion", minimally.

I think you could build a rainbow table for traditional passwords, but the code_verifier is not a password in the sense that it is created by a human. It is a high-entropy cryptographically random sting, meaning no possibility is any more likely than the other, nor can we guess what it will be.

We already expect it will be computationally slow to create the lookup table, but I'd argue that it's infeasible to store also.

But even still, there is more to consider. Since the authorization code is short-lived and single-use, this means that the attacker gets one chance per OAuth flow to get it right.

From RFC-6749 "The OAuth 2.0 Authorization Framework"

Authorization codes MUST be short lived and single-use. If the authorization server observes multiple attempts to exchange an authorization code for an access token, the authorization server SHOULD attempt to revoke all access tokens already granted based on the compromised authorization code.

Please be aware that PKCE actually demands that SHA-256 is used if this capability is present in the client.

From RFC-7636 "Proof Key for Code Exchange by OAuth Public Clients"

If the client is capable of using "S256", it MUST use "S256", as "S256" is Mandatory To Implement (MTI) on the server. Clients are permitted to use "plain" only if they cannot support "S256" for some technical reason and know via out-of-band configuration that the server supports "plain".

The plain transformation is for compatibility with existing deployments and for constrained environments that can't use the S256 transformation.

Honestly, it seems that if the attacker can intercept the code_challenge, then he should just try using it as-is when trying to bypass PKCE.

Upvotes: 3

Michal Trojanowski
Michal Trojanowski

Reputation: 12342

You hash the code verifier to make it even harder for an attacker to steal it. If they manage to somehow intercept the code challenge sent in the authorization request, it is still not enough, as you need the original code verifier to exchange the authorization code for an access token. It's just another measure that increases the level of security in PKCE.

It's not obligatory to hash the code verifier, by the way. One of the "hashing methods" in the specification is "plain", which means that you don't hash the verifier. Though it is recommended to hash it, if there are no obstacles to do that.

Upvotes: 4

Related Questions