Why is the refresh token hashed twice before it's stored in the db?

[rishabhpoddar]

No description provided.

[rishabhpoddar]

Because we need to store some reference of the refresh token in the access token too. We can't store it in plain text in there, so we must hash it in order to store it in the access token.

Since we are "sending out" the hash of the refresh token, it can potentially be read if the access token is stolen.

If in the future, there is an API that reads the hash of the refresh token (from the access token) to do some operation that is mutating in nature, then this hashed refresh token might also become a sensitive token.

In general, we want to minimise the set of sensitive tokens stored in the db. So we don't want to store the hashed refresh token either (for future possible changes). So we stored the double hash.

One might argue that this is not really adding any security as of today, and may never add any in the future either (if no such API that takes hash(refresh token) comes along). But then doing another hash before storage is a very cheap operation anyway.. So might as well.

[DerZade]

I think this does not only have security implications for possible future changes, but for the current API as well.

Take the following scenario: The DB holds the normal-hashed version of the RT and an attacker get's a dump of the DB.

Now the attacker would have everything to create a valid refresh token, that would be accepted by the backend:

• The key to generate RTs (it's also in the DB)
• Session handle
• User ID
• The hash of the of current RT (which can be used as the parent RT hash within the session-token)

The API would think the attacker's token is a child-token of the current token and it would therefore be accepted.

[rishabhpoddar]

oh yea! Agreed! Thanks. Had slipped out of my mind. This was the exact reason for why it was being hashed twice :)