128 bits of entropy cannot give probability of guessing below 2^-160

[James Manger]

Financial-grade API - Part 1: Read-Only API Security Profile (draft 05, 2018-08-29) section 5.2.2. "Authorization server" point 16 says:

"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;"

You need at least 160 bits of entropy (not 128) for the probability of guessing a token to be less than 2^(-160).

[Joseph Heenan]

There was some discussion about this in https://bitbucket.org/openid/fapi/issues/132/requirement-on-token-lengths-may-less-than when we added the guessability requirement.

To summarise what I remember: The consensus was that the overall probability of guessing a token is related to more than just the entropy, as the AS may have other mechanisms in place that prevent multiple attempts at guessing tokens (eg. rate limiting / blacklisting / etc).

The 128 bits is an absolute minimum, and ASs are free to issue tokens with more entropy if that is how they want to meet the probability requirement. To quote https://bitbucket.org/openid/fapi/commits/0767a115d56c :

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 attempts to use bad access tokens.

[Nat Sakimura]

Add more explanation why 128 bit may be fine as there are other ways than just entropy in the token.

[Tom Jones]

I thought we went over that a year ago. I can give you the official Microsoft Windows position on this issue as of 2010 as i was the one to make it from windows security to the fusion team. 128 bits is more that enough to avoid collisions to a sufficient degree that you do not need to take measures to handle collisions on over one billion computers spread across the globe. Anti-hammering mitigation requirements would be a better condition to add the the spec that meeting this arbitrary goal.

[Dave Tonge]

We discussed changing the text to refer to RFC6749 10.10

[Dave Tonge]

we need to be aware of this: https://bitbucket.org/openid/fapi/pull-requests/171

[Brian Campbell]

So PR #171 currently has:

+1. shall provide opaque non-guessable access tokens, authorization codes and where applicable refresh 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’d propose we (well okay you really) update it to have the following text and that that be the resolution to this issue as well as Issue #240

+1. shall provide opaque non-guessable access tokens, authorization codes, and refresh tokens (where applicable), with sufficient entropy such that the probability of an attacker guessing the generated token is computationally infeasible as per [RFC6749] section 10.10;

[Brian Campbell]

^ back to you based on ^

[Joseph Heenan]

Thanks Brian.

‌

Just for clarity, we currently have a tests in the suite that fails implementations where:

1. the access tokens are less than 128 bits (or more accurately I think, 21 characters given you actually only get less than 6.12 bits per byte due to the limited character set)
2. the measured Shannon entropy of the token is less than 96 bits (the 96 bit limit deliberately being set lower to try and ensure there’s never a false failure due to the difficultly of measuring entropy).

Does the new text imply we need to adjust either of these tests?

‌

[Tom Jones]

I disagree with RFC 549 and hate to see it’s errors propagated. I wish Dick had come to talk to me when he made that statement as i owned the microsoft windows position at the time.

[Brian Campbell]

Joseph, I don’t think adjustments are needed.

[Joseph Heenan]

Great, thanks Brian, I like that answer

[Dave Tonge]

Thanks Brian - updated PR with your text is now here; https://bitbucket.org/openid/fapi/pull-requests/171/require-auth-codes-and-refresh-tokens-to/diff

[Dave Tonge]

PR merged in