Keys, Secrets, and Tokens

I have spent some of my time over the last 12 months working out how to improve our response to, first the Heroku leaks, followed later by the LastPass leaks, closely followed by the CircleCI leaks. Each of which took a significant amount of time to resolve, time that could have spent improving the features and capability of our main product.

Something I identified, as part of this response, was that as engineers, have several names for things that are very closely related, namely, Keys, Secrets and Tokens, there might even be others. I think any seasoned engineer will recognise that they do refer to different things, after all, we have AWS KMS and AWS Secrets Manager. But an IAM User has both keys and secrets and that keys is a different kind of key to the KMS key.

Having a common language reduces change fatigue and rework when a problem that everyone who thought they understood a problem discovered that they didn’t. This way we can have better confidence in the outcomes of the problem we’re discussing.

I needed a way of describing, without significant friction, a way to refer to values that are used by systems to interoperate (i.e.: not a password), are sensitive, and need careful management.

I decided that the best word to encompass this was Secret. It seemed like it had more meaning, in a more succinct way than any of the other terms available.

I proposed this to our business via our usual engineering approvals board and it got accepted.

It’s not to say that the usage of the word Key, or Token is banned, but that Secret emcompassed them all. The word Secret could also mean a key or a token. Something sensitive that needs protecting.

There are likely differences in each business that may mean that secret isn’t the right word for you, but having at least an awareness how these words mean similar, or different things can be helpful.