Password Management with a Difference: Part 2 Harnessing the Power of Pass and Git
A defining feature of all password managers is not only their ability to generate, store, and delete passwords. Rather, their popularity lies in the convenience they provide to the end users, one of these being syncing across devices. In this post, we are going to continue our discussion of the Pass Utility begun in the previous post.
While the simplicity of working with your passwords on your filesystem is what makes the Pass utility unique (in that passwords are simply encrypted files stored in a directory), the big question now is: is it convenient?
The convenience we want has to do with our ability to use passwords on any device under our control, including browsers and mobile platforms. If Pass could only be used on one machine, then its usefulness would be as good as an encrypted wallet on a single machine.
Pass and Git
Git is popular with developers for its management of source code repositories. It makes it easier to not only back up files, but even roll back any changes you might have made.
Pass uses this Git protocol to create a local repo which you can sync to a remote server.
There are many central Git management services such as GitHub, GitLab, and BitBucket. However, they all use the same protocol. This means that learning how to use Git on one platform will not jeopardise your chances of working with others.
So Pass can treat your local password store as a repo. For this to happen, you simply issue this command:
pass git init
As this is simply sending instructions to git, you need to have set some Git variables such as your username and email.
All git operations can be issued prefixed with the
Setting up Git
To take advantage of Git, soon after creating your store, do the following:
- Create a new Git account. For this purpose, we set up a git repo at GitHub.
- After creating an account, proceed to create a new repository.
- Name it whatever you like; however, let us just say
your-git-repothroughout this discussion.
- As this repository is not intended to be a collaborative repo, you
can make it private by checking the
Privatebox during the creation process or change the properties of the repository afterwards. Never mind about creating a new README file.
- After creating the repo, get its address. It can look something
firstname.lastname@example.org:username/your-git-repo.git1 You can get it by clicking on the
Codebutton when you open your repository homepage.
Next, associate your local Password Store (identified as a git repo) with your new repo at the Git service you’ve chosen such as Github in the above scenario.
To associate, do the following:
That repo you created is known as a remote repo.
Get into the Password Store. It is a hidden directory known as
.password-storeby default. So do the following:
Here, you are dealing with Git itself. We want to associate this directory with our newly-created repo. We do the following:
# We begin by adding the repository in the next line: git remote add origin https://github.com/username/your-git-repo.git # Then verify the addition as follows: git remote -v
And you are done here!
Every time you add, edit, or delete a password, this will be committed to your repo by the Pass utility without you doing much effort.
Of course, you have to update those commits with
pass git pushfor your remote repo to be updated.
On a new Machine
On a new machine, it will not be necessary to run the
commands for setting up your new Password Store. This is because you
already have a working Password volt along with a Git repository.
What you have to do is just install Pass and do not run a new init
command. Instead, change to your home directory with
cd ~/ and
clone your existing repo you set above. Just make sure the new clone
Some preliminaries on a new machine may involve importing your GPG key from the first device, or just copy the .gnupg directory. Then do the following:
git clone https://github.com/username/your-git-repo.git .password-store
And start using your Pass as usual.
Using Pass in the Browser and mobile platforms
While password management may be great on your machine, the convenience of any password manager comes with its interaction with the browser: after all, most of the services we consume are accessed via the browser.
For that reason, using Pass’s extensible interface, a number of extensions had been developed. For instance, there is Pasff for Firefox and Browser Plugin for Chrome.
To use Passff, though, you have to install a Bash script that makes it possible for your browser to communicate with your Pass Store. This way, you can fill in your service login pages with a click of a button.
Bear in mind that every time you install Firefox, Passff is not installed like other addons: instead you have to manually install the Bash script and the browser extension for this to work. You also must disable your browser’s autofill suggestion to store your password in its volt.
A Word of Caution
This post is posted under the “putting it together” section for a reason: it is not for the fainthearted. Setting up everything to work across devices may require not only patience but an understanding of what is going on with each piece of software you will be dealing with:
The Password Store itself;
Git repositories and their creation;
Installation of extensions: testing them and seeing how they work;
And an appreciation of security issues in general.
For example, trying to keep passwords on your machine requires that you do not be tempted to do the following:
Log into your system without prompt for your password.
Not securing your hard drive itself. Better encrypt your drive so that no one (except you) can boot into the system unless a correct password is entered.
When working in the graphical desktop such as Mate or Gnome, any time you enter a pass phrase to unlock a resource, a dialog box pops up with a checkbox to store this into its password vot. the advantage is that you will not enter your password every time you have to access the resource, instead the operating system will just fill it for you. The logic being that as you’ve already authenticated yourself when you logged in, you are still the same person who is requesting to access the resource. Please, do not be tempted to tick that box. It is better that
- whenever you push to your remote
repository, you enter your SSH pass phrase,
Or your password for your remote repo when using HTTPS,
- when you edit anything in the password store,
you enter your GPG pass phrase.
If this is a tall order, it is advisable to stick with other password managers such as Keepass, another great and opensource offering.
The pass utility places total control in your hands when it comes to password management. It is up to you to choose where to store your remote repository: this could be a popular Git central server like Github or your own server. However, this comes with responsibility of how good you are in securing your own data. Leaving your machine unattended, choosing shortcuts when it comes to logging in and such stuff may not be wise when working with Pass.
Ultimately, regardless of which Password management tool you choose, its effectiveness rests upon your choice of a master password and how you keep it. Thus, no matter how powerful a product may be, your actions as a user determine its efficacy.
The difference of the address has to do with whether you use SSH for managing your repositories or not. ↩︎