Bandwidth optimization by using token handle about automotive HOT 6 CLOSED

I agree , the attack vector should stay the same. It's a viable optimization, I don't have any objections. The question that perhaps someone should else with more in depth-knowledge should answer is whether 128-bit hash would be considered enough.

from automotive.

Regarding whether a 128-bit hash is enough or not, my view is that it has no security impact. If an attacker manages to obtain the token handle (=the hash), then it can use that in requests to the server, there is no need to obtain a copy of the real token.

from automotive.

Do we as part of the spec need to say anything on how long the the token handle shall be? A short token handle will make it easier to do a brute force attack, like trying with random token handles until you find one that match a usable token stored on server side. There it can be discussed if 128 bits is enough, but that could be a lengthy discussion and maybe we do not need to have it.

Maybe it is sufficient to say that the server MAY return a token handle, but the algorithm used to create it and the length of it is up to the server. That is OK as the client does not need to interpret it. Maybe we just need to specify format, like that it shall be a string. If a server returns a token handle the client can choose if it want to use the token or the token handle in subsequent requests.

from automotive.

Regarding the token handle size the PR says:
"If an access token is cached then the server shall compute a SHA-1 hash of the access token, which is then base64 encoded"
SHA-1 is 20 bytes, b64 encoding results in a token handle size of 28 bytes.

If an attacker gets possession of the token handle there is then no direct advantage to reconstruct the token from it, the handle is all the attacker needs to get access to the data.

How the handle is generated cold be left unspecified as the client does not need to decode it.
The text above, "the server shall compute" maybe should be "the server may compute" instead.
The entire text could also be removed completely, but recommending a solution may be helpful.

from automotive.

After some more thinking I came to the conclusion that the token handle is best represented by using the signature part of the actual token. The PR is updated with this solution.
I also added that the server may truncate the signature.

from automotive.

Fixed by PR#484

from automotive.