It's a common practice and a bad idea to send sensitive information over Slack or email. No matter how much you trust Slack or Gmail, there are types of company information (for example, SSH keys, certificates, security tokens...) that warrant an extra layer of security.

The challenge, then, is to create a more secure platform that is also easy to use in order to invite adoption.

A complicated way to tackle the issue

Being part of the security team, I send secrets and passwords on a daily basis. Existing ways of sending secure messages were quite cumbersome: you had to first ask the receiver to create a private and a public key, have them publish it somewhere like a web site, MIT’s public key service, or KeyBase, or send it directly to our squad. Only then we could start sending secure messages to each other.

While operations engineers are used to (if not happy with) this level of effort, asking other teams— dev, sales, marketing, execs — to indulge in such a procedure is simply not practical: I could already see employees reverting back to email or Slack.

Experience has shown us that the best way to mandate security measures is to make them as simple and easy to use as possible. Hence, I started racking my brain to find a new solution.

A solution is emerging

While working on a different project in our continuous efforts to make Algolia security top notch, I started using Hashicorp Vault. Vault “secures, stores, and tightly controls access to tokens, passwords, certificates, API keys, and other secrets in modern computing. Vault handles leasing, key revocation, key rolling, and auditing through a unified API”. Through Vault, Hashicorp changed the way companies store their secrets.

Digging a little deeper inside the Vault API and engine, I stumbled upon the concept of Response Wrapping. “Response Wrapping” is using Vault’s cubbyhole backend. Cubbyhole is a short-term storage place where you can put a secret that will be consumed by a user or a service who is holding a specific token. No token can access another token's cubbyhole, whether to read, write, list, or for any other operation. When the token expires, its cubbyhole is destroyed.

So, a Vault token has all the features we need to create a self-destructing message service:

1. TTL - a time during which the token will be alive
2. Number of uses - the number of times you can use the token
3. Cubbyhole - a special place where we can save secrets

Let’s put all of these features into use and create a secret message service workflow:

1. User inputs secret message
2. Create a token with TTL=24Hours and NumberOfUses=2
3. Write the secret to the “cubbyhole”
4. Token NumberOfUses - 1 = 1
5. Give the token back to the user
6. User sends token to relevant recipient
7. Recipient uses token to open the secret message in cubbyhole
8. Token NumberOfUses - 1 = 0 ; hence the token and secret are deleted
9. Success!! \o/

Yet Another Secret Messaging Service?

Now, before building the final tool, I did some research to make sure I am not reinventing the wheel. I decided to look for a self-destruct messaging software, and found a couple of candidates, but they all had at least one of the following issues:

• They didn’t allow the option of self hosting, which made security an issue, thus defeating the purpose
• Not simple enough to use
• They required a complex deployment on the user’s part, such as installing Redis, Node and other dependencies
• The backend storage is typically not that secure
• They are not open source

I don't explicitly list the tools because the "domain" of secret messaging services is so tiny. But I believe your own research will take only a few minutes to come to the same results as I have. Check out these awesome self-hosted pastebins.

The research justified building a new tool with the following requirements:

• Hosted on our server (aka super secure) easy to deploy
• Ease of use
• Using Hashicorp Vault (nust as an experiment)

All I had to do now is create a very simple API with 2 public methods:

• SetSecret - which puts the secret in Vault and returns a token
• GetSecret - uses the token and gives back the secret

On top of that I built a very simple web UI:

1. You insert your secret, submit it

2. You get a URL with the one time token

3. You send the URL to the happy recipient via Slack or email

4. She opens the secret message

5. If you try to open the message again

And that’s all there is to it!

While this was at first just an experiment in using Hashicorp Vault for a secret messaging tool, it has really caught on at Algolia, where I see many coworkers using it for all kinds of secrets sharing.

If you like my sup3rS3cretMes5age tool, you can try it yourself on GitHub. It's open source :)