Rotating hashing key for access token

[minzcmu]

Context

With our current code logic, it's impossible to rotate the one way hashing key/salt for access tokens without invalidating current tokens.

https://github.com/screwdriver-cd/models/blob/master/lib/generateToken.js#L35

Possible solution

• Inform users, rotate the hashing key and ask users to refresh it
• Double/triple encryption: maintain a map of hashing keys, encrypt current hash value with new key, and when trying to fetch: encrypt with all keys in the map and then compare
• Switch to Bcrypt: bcrypt will generate a random salt for every token. We don't need a hashing key going forward. But need to change the access token interface to ask users to use it with pipelineId/userID, e.g. pipeline123:tokenvalue. So that we can look up the tokens for pipeline 123, and compare the hash values.

[FenrirUnbound]

I guess what's missing in the context is the "why do we want to rotate the salt". The stance we took was that the access token was treated like a password-alternative, and just like passwords, changing it has to be intended by the user.

Of course, long-lived passwords is a potential security threat (e.g., a common IT policy is to rotate your password every n days). Our solution was to put a TTL on the token. This touches on your 2nd bullet point, and also limits the number of salts you need to maintain. Once a salt has reached it's TTL, you can treat all the access tokens created with it to be considered invalid.