How to store your little secrets.
Tags: security, unix, shell, opensource
Published: 2020-05-01 18:45:00


First of all, when I say *little secret*, I mean all the passwords, passphrases or private keys you use everyday, everywhere. So, a passphrase protected SSH private key is... **not** a little secret.

## It was better before... <small>but, that was before.</small>

Not so long ago, it was common to use very simple passwords and even the same one in several places or with tiny variations. It was a perfectly normal and predictable behavior. It turned out to be a very bad idea. It was just as predictable, you might say.

Today, all services, and especially websites, force us to use passwords that are increasingly unpredictable. Sometimes, this password is even imposed to us! This practice is rarely justifiable, but never mind. Things quickly become unmanageable...

We are not able to keep all of these unpredictable things in our little heads, at least not me, and that's perfectly fine. 

A little secret being a secret, we don't want to store it in plain text either. Then we might want to encrypt it. In doing so, and remembering our definition, it is no longer a little secret. It has been replaced by a new one, the one used to decrypt it! This leads us to the inevitable conclusion that:

**Little secrets are hard to store, because you can only memorize them!**

There's an obvious solution to this problem. We simply encrypt all of these little secrets with a shiny new and unique little secret! As it is unique let's call it the *master key*.

This solution has a name and you probably know it because you already use it: the *password manager* (like your browser). But, for the purposes of this article, let's rename it the *secret's daemon*. The word *manager* was too evil.

What a happy ending! We finally only have one little secret to keep. So, as before, and for the same reason as before, it must be easy to remember. Because... it was better before.

## The road to hell... <small>is paved with good intentions.</small>

Without even realizing it, you end up securing your entire digital life with a little and simple secret: mails, social networks, online shops, legal identifiers and maybe even your professional secrets... You better not disclose it by mistake!

I never really liked it. I've always tried very hard to use multiple master keys to avoid falling into this trap. And I did well! It has happened to me to disclose some secrets unwittingly and even several times. Well, I have to admit, I'm a very distracted person.

Let me put it to you another way. You signed a contract, with your blood, that allows a secret's daemon to keep the most important things of your digital life for a small, easy to remember, word. So that you'll never have to remember those horrors ever again... Better ?

Okay, maybe I'm being a little cranky. And I don't want you to think I'm saying we shouldn't use our new demonic friend. As I said above, some people impose you to keep completely random secrets and there's no way you're going to learn them... That would be neural wastage!

What I want to show you is that there is a middle ground between the two extremes and it seems to me much better. But first, I want to show you the problem I was facing at the beginning.

## Tech for good... <small>and not for fun.</small>

If you use a UNIX system like me and your productivity is directly related to the use of a terminal then you have certainly solved the problem of storing your secrets by finding the ideal daemon for you.

Let's say you use the `pass` command which uses `gpg` as a backend (they almost all do this and for good reason). You may have noticed that there is a timeout for the master key retention. It's quite annoying and people often increase the default value. It's unfortunately a bad idea. This delay is here for a very good reason. Indeed, almost all software running on your machine can read all your secrets during this period.

As an example, you can look at this little script that will allow you to reveal all your secrets if, somewhere, you used `pass`. Nice.

```sh
#!/bin/sh
find ~/.* -name '*.gpg' | while read -r K _ ; do
        K="${K##*d-store/}"
        K="${K%.gpg}"
        echo "--- $K ---"
        timeout 2 pass "$K" 2>/dev/null </dev/null
done
```

And of course, we can't trust everything we run on our machines. I don't go through the `./configure` script when I want to install new software from source, or the 2000-lines shell script I just piped from `curl` to `sh`. But these are things I do all the time.

On the other hand, I cannot disable the `gpg-agent`. The master key is the most important secret of our digital life! The more we have to use it, the more we increase the risk of disclosing it. For example by typing it in the wrong window in a hurry... Ideally, I would like to type it only once per session.

Until now I used several user accounts with different master keys (and some other things) to properly separate my activities. It was very annoying on many aspects but it was doing the job.

## <small>And then came...</small> The Quarantine.

With all this time available in front of me, I decided to write a small tool, [secret](github.com/angt/secret), to solve the problems I had with `pass` and `gpg`, mainly:
 - Supports many passphrases to drastically simplify my old habits.
 - With an agent who doesn't need this annoying timeout to be secure.
 - And finally, being able to store all my secrets on my [dotfiles](github.com/angt/dotfiles) without fear.

The whole crypto part was very easy to set up thanks to the wonderful [hydrogen](https://github.com/jedisct1/libhydrogen) library.

While working on this new tool, I was thinking about how I was using passwords so far to see what I could improve. And I realized that what I was doing was in fact unnecessarily complicated.

Now we can go back to the original question, slightly restated :)

## How to *memorize* your little secrets ? <small><br>...Because we can't store them.</small>

Let's take an example, we want to register for a new awesome mail service  and the new mail is going to be `we@awesome.mail`.

Usually the secret's daemon will give us a randomly generated password. It will be encrypted with one of our master keys and we will have to store it somewhere and then sync it everywhere. Then, one day, we will have to update it and resynchronize everything...

In fact, it is possible to produce a secret that seems totally random when it is completely determined by some little secrets. This is well known and this changes everything.

Let me show you how the command `secret pass` can help us.
So we want a secret for a mail called `we@awesome.mail` for 2020 ? Easy:

```
$ secret pass mail we@awesome.mail 2020
Passphrase: 
z>mWPui2rt7+yRm%:nky^Z5vR
```

This secret was generated in a completely determined way. We will get the same answer everywhere if we use the same little secrets: the master key and the words: `mail`, `we@awesome.mail` and `2020`. Which become little secrets. And they are not so hard to remember :)

Now we want to update our password for 2021. Let's see what happens if we do like before:

```
$ secret pass mail we@awesome.mail 2021
Passphrase:
dnC7LI9B'la;_9r]\RP`;+Wp*
```

Nice! Even if only one byte has changed, the new secret is totally different and, fortunately, safe to use.

It is important to note that you are, of course, completely free to choose the words used here. There are no rules. It is up to you to make your sentences in such a way that you will never forget it!

**In conclusion:** We have a perfectly safe password to use for our new mail. **Nothing has been stored** and there's **nothing to synchronize**! It couldn't be simpler!

That's all! But much longer than expected!
Thank you for taking the time to read all the way through! I hope you enjoyed it. I would be happy to hear your comments and answer your questions, so feel free :)

**Note 1:** `secret` is very young project. **Do not use it for serious things yet.**

**Note 2:** I should point out that in reality you also need the same `~/.secret` file to have exactly the same generated secret. But it's a choice to improve the overall security of the tool. Nothing imposes it.