Bandwidth optimization by using token handle

[UlfBj]

The access token that a client must include in a request to get access controlled data is typically a size of 1k-2k bytes. The token may have a lifetime that allows it to be used multiple times by the client, which then according to the current spec must include it in every request. If the server cached the token at the first reception of it, and after successfully validating it, and in the response returned a "token handle", then the client could replce the token with this handle in subsequent requests. The token handle could be a hash of the token. If using a 128 bit hash, and encoding it using base64, it would lead to a token handle size of 24 bytes. The following requests may contain a token:

• Get
• Set
• Subscribe So the responses of these request would have to b extended with an optional parameter, a token handle. It would follow the pattern for tokens and be included in a header for HTTPS, and in the payload for the other protocols. The server would have to revalidate the token at each reception of a token handle, and purge its cache when a token expires. I believe that from a security point of view this does not open any new attack vectors, the risk for an attacker to intercept the token, or the token handle, should be the same.

[petervolvowinz]

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.

[UlfBj]

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.

[erikbosch]

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.

[UlfBj]

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.

[UlfBj]

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.

[UlfBj]

Fixed by PR#484