Use of pass for security classification

An earlier missive: command-line-passwords-with-pass talks about setting up pass and how to get to grips with general use of this the the standard unix password manager

Using pass can equate itself to becoming a very personal experience in my view and getting to know how to use it is a lot down to how you tend to use pass, Git and GPG. I believe it can say a lot about how you feel about security.

If all your secrets are in the one place, that is a single location to secure and lock down but if it is the only place you store your data then it is by nature, a single point of failure.

For the sake of securely backing our data up, why not have at least 2 copies ?

However, that is not a real backup in the truest sense, is it ?

So lets have 2 copies that are as backups .plus. the origonal ‘single source of truth’, so that is 3. Oh, and while we are at it, lets have another remote ( off site as it is often called ) copy somewhere else.

Some folks see this as the only way to do a ‘real backup’ and one that assures us that if the on site data is lost, there is at least 1 other place we can go to to restore our data.

We could also have generations of backups at one or more off site locations.

‘You can’t have enough backups’

I remember being told to me one time and its stuck in my head to this day.

There is another way of looking at passwords and / or secure data and that could be how we classify that data and thus where we have copies of it.

Where we have very sensitive data, it would be logical to only have that data on systems that we trust in an ‘ultimate’ way so these could be systems that we own, manage and trust to be secure and only accessed by us or those that we have similar trust to that of ourselves.

If we have other data that is say, important but not as sensitive, lets call this ‘configurations’ for example which could be things we need to back up but not have in a public repository, then these could be candidates for an alternative security and storage classification.

How can this ‘classification’ be done in a simple and straight forward way with pass ?

Simple really, we can set an environment variable straight from man pass namely

PASSWORD_STORE_DIR
   		Overrides the default password storage directory.

Once set to something different to the default that is ~/.password-store/ from here on in, pass will only use the directory we have now told it to use with something like :

export PASSWORD_STORE_DIR=~/.other-password-store

Now, when we run pass on a system that has already been set up to use pass, its like we never set it up :

pass
Error: password store is empty. Try "pass init".

We need to set up pass like we started over but our new password data will be separate to the default location of ~/.password-store that we had up to this point. Different kinds of data can be stored in each new vault so to speak and even have the git data stored or rather pushed to other locations, not just a single Git repo we set up for our default vault. Differently classified data, locations to which we push the data to, even completely different infrastructures is possible with the same pass command line tool.

We might trust some copies to be on public cloud services like github, gitlab, bitbucket and so on as private or even public repositories, dependent upon the sensitivity of that data and the GPG private key used to secure that data. Thus when we initialise the repository of a new vault in the above manner, we would logically pick a GPG private key that is different for the new vault and its data :

pass init -p / A_DIFFERENT_GPG_KEY

This data is still encrypted and it will be just as securely encrypted but we may choose to have this particular vault cloned to other locations that are more easily accessible to production infrastructure.

The security of our secrets and credentials is something we need own and take personal responsibility.

In days before, when humans hunted to survive, did they do so with blunt instruments ? By no means, they made sure that their hunting equipment was as well maintained as possible so as to ensure they they could hunt, fish or gather sufficient to survive and to provide for dependants.

Today, we too when forageing on the Internet need to do so with similar care, caution and due diligence and have our security knowlege and tools appropriately sharp and ready for use.