Requirement on token lengths may less than core OAuth requires

[bitbucket-import-issues]

Originally submitted by josephheenan (Joseph Heenan) on 2018-02-01

FAPI Part one says:

[the AS] shall provide opaque non-guessable access tokens with a minimum of 128 bits as defined in section 5.1.4.2.2 of [RFC6819].

whereas https://tools.ietf.org/html/rfc6749#section-10.10 says :

The authorization server MUST prevent attackers from guessing access tokens, authorization codes, refresh tokens, resource owner passwords, and client credentials.
The probability of an attacker guessing generated tokens (and other credentials not intended for handling by end-users) MUST be less than or equal to 2^(-128) and SHOULD be less than or equal to 2^(-160).

To me, that makes the requirement in FAPI too weak. 128 bits of length (where the token is only using ASCII) is less than 112 bits of entropy.

We'd need to be insisting on something over 182 bits to come anywhere close to meeting that 'SHOULD' I believe?

---

Bitbucket status: resolved

Bitbucket origin: issue 132

[bitbucket-import-issues]

Originally submitted by Ralph Bragg (Ralph Bragg) on 2018-02-01

Joseph, I completely agree, i believe the majority of the openbanking ASPSPs are using encrypted JWTs as the access token which should meet this requirement. Can you let me know if you've found any that aren't and i'll get this clarified by the ISWG.

[bitbucket-import-issues]

Originally submitted by Nat (Nat Sakimura) on 2018-02-01

Good catch. Actually, we should file an errata against RFC6819 as well on this one.

For Part 1, we should change 5.2.2 -16 as

16. shall provide opaque non-guessable access tokens with a minimum of 128 bits of entropy

[bitbucket-import-issues]

Originally submitted by josephheenan (Joseph Heenan) on 2018-02-01

Nat I don't believe that's sufficient to comply with RFC6749 either. If you have exactly 128 bits of entropy but the AS has issued two access tokens, then your probably of guessing the token is higher than 2^(-128) by a tiny amount. As the number of access tokens issued by the AS increases, the probability of a correct guess increases.

I will suggest some wording. Perhaps just suggesting 192 or 256 bits of entropy is the easiest solution?

(Just as an aside, I tried to work out the mapping between entropy and token length: If we assume a base64 / base64url encoded token, you get [at most] 6 bits of entropy per byte, so a token with 128 bits of entropy has a minimum length of 22 characters or 171 bits.)

[bitbucket-import-issues]

Originally submitted by josephheenan (Joseph Heenan) on 2018-02-05

Pull request raised here with suggested new wording:

https://bitbucket.org/openid/fapi/pull-requests/45/bring-access-token-requirements-inline/diff

[bitbucket-import-issues]

Originally submitted by tomcjones (Tom Jones) on 2018-02-07

looking at https://tools.ietf.org/html/rfc6750#section-2.1
it seems that authorization bearer tokens can be placed in a url in the general case
So the token should not be expanded for all uses beyond what is necessary
these are visible to many attackers and should remain secure.
While i have no problem with a token in a body requiring 30 characters, i worry about the url case
I will try to get a better meaning of "guess-ability" but looking at the docs, that might take a while.
so if you need to progress, i would not object to an intermediate value, especially of the security concerns and options were spell out. I will try to do that after dinner.

[bitbucket-import-issues]

Originally submitted by tomcjones (Tom Jones) on 2018-02-07

Good morning - i reviewed the guess-ability literature and found that while good formulae exist, the calculations are are more involved than i care to make (https://arxiv.org/pdf/1507.02342.pdf). In any case my objection on length is probably not so important if talking about 22 characters versus 30 characters. Still we are talking about one chance in 340 billion billion billion billion versus one chance in 340 thousand billion billion billion. Not a problem i worry about. The proposed rewording is really hard for an SDE to read, Also the issue is the number of valid tokens at any one time, which is not clear. my calculation is that at most 166 bits of entropy are to be required, which can be encoded in 28 ascii characters, which is what the SDE wants to know.

shall provide opaque access tokens where the probability of an attacker guessing the generated token is less than or equal to 2^(-160). For example, on a server which issues less than 1,000,000 access tokens a token length of 240 bits with 180 bits of entropy meets this requirement;
+>>>

[bitbucket-import-issues]

Originally submitted by josephheenan (Joseph Heenan) on 2018-05-04

Apologies for the delay. I've spent a little while considering this today and I'd like to suggest this:

shall provide opaque non-guessable access tokens 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;

I have deliberately removed the reference to RFC6819, as it seems to be talking solely about token length when it refers to 128bit.

Please let me know your thoughts.

[bitbucket-import-issues]

Originally submitted by Nat (Nat Sakimura) on 2018-06-12

Bring access token requirements inline with RFC6749 section 10.10

Our previous minimum on the length of the token appears to be lower
than RFC6749 calls for.

To address this we take two actions:

1. Change from 128 bit token to token with 128 bits of entropy

2. We take the 'should' clause from RFC6749, turn it into a shall
   (which seems reasonable given FAPI needs to be hitting the high end
   of any security requirement, and add a practical example to avoid
   misinterpretation of the requirement.

Based on the assumption that a token can only have a maximum of 6 bits
of entropy for each 8 bit byte (which mainly comes from the requirement
that tokens can only use some subset of ASCII) this implies the token
needs to be at least 22 characters long.

It is left as an exercise for the implementor how to fully achieve the
guessability restriction in RFC6749, for example through the use of
rate limiting or IP blacklisting for repeated attempst to use bad
access tokens.

fixes #132

→ <<cset 0767a11>>