128 bits of entropy cannot give probability of guessing below 2^-160
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).
Comments (19)
-
-
- changed status to open
Add more explanation why 128 bit may be fine as there are other ways than just entropy in the token.
-
-
assigned issue to
-
assigned issue to
-
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.
-
-
assigned issue to
We discussed changing the text to refer to RFC6749 10.10
-
assigned issue to
-
we need to be aware of this: https://bitbucket.org/openid/fapi/pull-requests/171
-
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;
-
-
assigned issue to
^ back to you based on ^
-
assigned issue to
-
Thanks Brian.
Just for clarity, we currently have a tests in the suite that fails implementations where:
- 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)
- 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?
-
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.
-
Joseph, I don’t think adjustments are needed.
-
Great, thanks Brian, I like that answer
-
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
-
- changed status to resolved
PR merged in
-
- changed component to Part 1: Baseline
-
- changed component to FAPI 1 - Part 1: Baseline
-
- changed component to FAPI 1 – Part 1: Baseline
-
- changed component to FAPI 1 – Baseline
-
- changed component to FAPI 1: Baseline
- Log in to comment
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 :