it's okay if a refresh token can be guessed?

[bitbucket-import-issues]

Originally submitted by Brian Campbell (Brian Campbell) on 2020-11-18

Baseline has "Access tokens shall be non-guessable with a minimum of 128 bits of entropy where the probability of an attacker guessing the generated token is less than or equal to 2^(-160) as per [!RFC6749] section 10.10."

Should ATs be the only artifact for which we give such requirements?  There are also refresh tokens, authorization codes, request_uri values from PAR, and maybe other stuff I'm forgetting.

---

Bitbucket status: resolved

Bitbucket origin: issue 345

[bitbucket-import-issues]

Originally submitted by Daniel Fett (Daniel Fett) on 2020-11-20

(We just hope that the attacker gets tired guessing access tokens and does not see the static authorization codes. /s)

We have a similar clause in FAPI 1 as well. (The requirement on other types of tokens got lost somewhere on the way from FAPI 1 to 2.)

But I wonder if we can’t omit this whole clause from both FAPI versions — after all, it refers to a requirement in RFC6749 anyway, and PAR URIs are covered in the PAR draft as well. So there is really no point here other than reminding people of existing requirements.

Any other views on this?

[bitbucket-import-issues]

Originally submitted by josephheenan (Joseph Heenan) on 2020-11-20

The text is subtly different to 6749 (the FAPI text clearly requires 128 bits of entropy, I find statements about “probability” to be less clear) and is more testable.

With my certification hat on I’ve had a surprising/depressing number of non-trivial conversations about why using 8 character authorization codes is not acceptable in FAPI…

‌

‌

[bitbucket-import-issues]

Originally submitted by Brian Campbell (Brian Campbell) on 2020-11-20

While the requirements are inherited from other specs and could be omitted, it does seem like an explicit reminder is worthwhile. And I’m thinking that reminder shouldn’t single out a particular artifact type as that could potentially be read as omitting the other stuff from the requirement.

What about something like this?

Credentials not intended for handling by end-users (e.g., access tokens, refresh tokens, authorization codes, etc.) shall be created with sufficient entropy such that an attacker correctly guessing the value is computationally infeasible as per Section 10.10 of RFC6749.

‌

[bitbucket-import-issues]

Originally submitted by Daniel Fett (Daniel Fett) on 2020-11-25

Joseph Heenan I only see the 128 bits of entropy mentioned for the client secret in FAPI 1. I agree with you that probability is not clear enough - we would need to describe many more variables (e.g., how often can an attacker guess?). What do you think about the following text?

Credentials not intended for handling by end-users (e.g., access tokens, refresh tokens, authorization codes, etc.) shall be created with at least 128 bits of entropy such that an attacker correctly guessing the value is computationally infeasible. Cf. Section 10.10 of RFC6749.

‌

[bitbucket-import-issues]

Originally submitted by dgtonge (Dave Tonge) on 2020-11-25

I like the revised test from Daniel

[bitbucket-import-issues]

Originally submitted by dgtonge (Dave Tonge) on 2020-11-25

we agreed on the call to go with Daniel’s proposed text

[bitbucket-import-issues]

Originally submitted by Daniel Fett (Daniel Fett) on 2020-12-16

Fix #345

→ <<cset 24deefa>>