The paint is chipped. There is a little rust on the gate. The hook has been reshaped by almost a decade of rubbing by a split ring. It still works as good as the day I bought it.
If you need to hang something off your belt, seriously consider the Maxpedition Keyper.
The first password manager I ever used was a simple text file encrypted with GnuPG. When I needed a password I would decrypt the file, read it in Vim, and copy the required entry to the system clipboard. This system didn’t last. At the time I wasn’t using GnuPG for much else, and this was in the very beginning of my Vim days, when the program seemed cumbersome and daunting. I shortly moved to other, purpose-built password managers.
After some experimentation I landed on KeePassX, which I used for a number of years. Some time ago I decided that I wanted to move to a command-line solution. KeePassX and a web browser were the only graphical applications that I was using with any regularity. I could see no need for a password manager to have a graphical interface, and the GUI’s dependency on a mouse decreased my productivity. After a cursory look at the available choices I landed right back where I started all those years ago: Vim and GnuPG.
These days Vim is my most used program outside of a web browser and I use GnuPG daily for handling the majority of my encryption needs. My greater familiarity with both of these tools is one of the reasons I’ve been successful with the system this time around. I believe the other reason is my more systematic approach.
The power of this system comes from its simplicity: passwords are stored in plain text files that have been encrypted with GnuPG. Every platform out there has some implementation of the PGP protocol, so the files can easily be decrypted anywhere. After they’ve been decrypted, there’s no fancy file formats to deal with. It’s all just text, which can be manipulated with a plethora of powerful tools. I favor reading the text in Vim, but any text editor will do the job.
All passwords are stored within a directory called ~/pw. Within this directory are multiple files. Each of these files can be thought of as a separate password database. I store bank information in financial.gpg. Login information for various shopping websites are in ecommerce.gpg. My email credentials are in email.gpg. All of these entries could very well be stored in a single file, but breaking it out into multiple files allows me some measure of access control.
I regularly use two computers: my laptop at home and a desktop machine at work. I trust my laptop. It has my GnuPG key on it and it should have access to all password database files. I do not place complete trust in my machine at work. I don’t trust it enough to give it access to my GnuPG key, and as such I have a different GnuPG key on that machine that I use for encryption at work.
Having passwords segregated into multiple database files allows me to encrypt the different files to different keys. Every file is encrypted to my primary GnuPG key, but only some are encrypted with my work key. Login credentials needed for work are encrypted to the work key. I have no need to login to my bank accounts at work, and it wouldn’t be prudent to do so on a machine that I do not fully trust, so the financial.gpg file is not encrypted to my work key. If someone compromises my work computer, they still will be no closer to accessing my banking credentials.
The ~/pw directory is a git repository. This gives me version control on all of my passwords. If I accidentally delete an entry I can always get it back. It also provides syncing and redundant storage without depending on a third-party like Dropbox.
An advantage of using a directory full of encrypted files as my password manager is that I’m not limited to only storing usernames and passwords. Any file can be added to the repository. I keep keys for backups, SSH keys, and SSL keys (all of which have been encrypted with my GnuPG key) in the directory. This gives me one location for all of my authentication credentials, which simplifies the locating and backing up of these important files.
Each file is structured with Vim folds and indentation. There are various ways for Vim to fold text. I use markers, sticking with the default {{{/}}} characters. A typical password entry will look like this:
1 2 3 4 5 | |
Each file is full of entries like this. Certain entries are grouped together within other folds for organization. Certain entries may have comments so that I have a record of the false personally identifiable information the service requested when I registered.
1 2 3 4 5 6 7 8 | |
Following a consistent structure like this makes the file easier to navigate and allows for the possibility of the file being parsed by a script. The fold markers come into play with my Vim configuration.
I use Vim with the vim-gnupg plugin. This makes editing of encrypted files seamless. When opening existing files, the contents are decrypted. When opening new files, the plugin asks which recipients the file should be encrypted to. When a file is open, leaking the clear text is avoided by disabling viminfo, swapfile, and undofile. I run gpg-agent so that my passphrase is remembered for a short period of time after I use it. This makes it easy and secure to work with (and create) the encrypted files with Vim. I define a few extra options in my vimrc to facilitate working with passwords.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 | |
The first two options simply tell vim-gnupg to always ASCII-armor and sign new files. These have nothing particular to do with password management, but are good practices for all encrypted files.
The first autocmd calls a function which holds the options that I wanted applied to my password files. I have these options apply to all encrypted files, although they’re intended primarily for use when Vim is acting as my password manager.
The primary shortcoming with using an encrypted text file as a password database is the lack of protection against shoulder-surfing. After the file has been decrypted and opened, anyone standing behind you can look over your shoulder and view all the entries. This is solved with folds and is what most of these extra options address.
I set foldmethod to marker so that Vim knows to look for all the {{{/}}} characters and use them to build the folds. Then I set foldclose to all. This closes all folds unless the cursor is in them. This way only one fold can be open at a time – or, to put it another way, only one password entry is ever visible at once.
The final fold option instructs Vim when it is allowed to open folds. Folds can always be opened manually, but by default Vim will also open them for many other cases: if you navigate to a fold, jump to a mark within a fold or search for a pattern within a fold, they will open. By setting foldopen to insert I instruct Vim that the only time it should automatically open a fold is if my cursor is in a fold and I change to insert mode. The effect of this is that when I open a file, all folds are closed by default. I can navigate through the file, search and jump through matches, all without opening any of the folds and inadvertently exposing the passwords on my screen. The fold will open if I change to insert mode within it, but it is difficult to do that by mistake.
I have my spacebar setup to toggle folds within Vim. After I have navigated to the desired entry, I can simply whack the spacebar to open it and copy the credential that I need to the system clipboard. At that point I can whack the spacebar again to close the fold, or I can quit Vim. Or I can simply wait.
The other special option I set is updatetime. Vim uses this option to determine when it should write swap files for crash recovery. Since vim-gnupg disables swap files for decrypted files, this has no effect. I use it for something else.
In the second autocmd I tell Vim to close itself on CursorHold. CursorHold is triggered whenever no key has been pressed for the time specified by updatetime. So the effect of this is that my password files are automatically closed after 1 minute of inactivity. This is similar to KeePassX’s behaviour of “locking the workspace” after a set period of inactivity.
To easily copy a credential to the system clipboard from Vim I have two shortcuts mapped.
1 2 3 4 5 | |
Vim can access the system clipboard using both the * and + registers. I opt to use + because X treats it as a selection rather than a cut-buffer. As the Vim documentation explains:
Selections are “owned” by an application, and disappear when that application (e.g., Vim) exits, thus losing the data, whereas cut-buffers, are stored within the X-server itself and remain until written over or the X-server exits (e.g., upon logging out).
The result is that I can copy a username or password by placing the cursor on its first character and hitting <leader>y. I can paste the credential wherever it is needed. After I close Vim, or after Vim closes itself after 1 minute of inactivity, the credential is removed from the clipboard. This replicates KeePassX’s behaviour of clearing the clipboard so many seconds after a username or password has been copied.
Passwords should be long and unique. To satisfy this any password manager needs some sort of password generator. Vim provides this with its ability to call and read external commands I can tell Vim to call the standard-issue pwgen program to generate a secure 24-character password utilizing special characters and insert the output at the cursor, like this:
1 | |
The ~/pw directory is backed up in the same way as most other things on my hard drive: to Tarsnap via Tarsnapper, to an external drive via rsnapshot and cryptshot, rsync to a mirror drive. The issue with these standard backups is that they’re all encrypted and the keys to decrypt them are stored in the password manager. If I loose ~/pw I’ll have plenty of backups around, but none that I can actually access. I address this problem with regular backups to optical media.
At the beginning of every month I burn the password directory to two CDs. One copy is stored at home and the other at an off-site location. I began these optical media backups in December, so I currently have two sets consisting of five discs each. Any one of these discs will provide me with the keys I need to access a backup made with one of the more frequent methods.
Of course, all the files being burned to these discs are still encrypted with my GnuPG key. If I loose that key or passphrase I will have no way to decrypt any of these files. Protecting one’s GnuPG key is another problem entirely. I’ve taken steps that make me feel confident in my ability to always be able to recover a copy of my key, but none that I’m comfortable discussing publicly.
I’ve defined a shell function, pw(), that operates exactly like the function I use for notes on Unix.
1 2 3 4 5 6 7 8 9 10 11 | |
This allows me to easily open any password file from wherever I am in the filesystem without specifying the full path. These two commands are equivalent, but the one utilizing pw() requires fewer keystrokes:
1 2 | |
The function changes to the password directory before opening the file so that while I’m in Vim I can drop down to a shell with :sh and already be in the proper directory to manipulate the files. After I close Vim the function returns me to the previous working directory.
This still required a few more keystrokes than I like, so I configured my shell to perform autocompletion in the directory. If financial.gpg is the only file in the directory beginning with an “f”, typing pw f<tab> is all that is required to open the file.
This setup provides simplicity, power, and portability. It uses the same tools that I already employ in my daily life, and does not require the use of the mouse or any graphical windows. I’ve been happily utilizing it for about 6 months now.
Initially I had thought I would supplement the setup with a script that would search the databases for a desired entry, using some combination of grep, awk and cut, and then copy it to my clipboard via xsel. As it turns out, I haven’t felt the desire to do this. Simply opening the file in Vim, searching for the desired entry, opening the fold and copying the credential to the system clipboard is quick enough. The whole process, absent of typing in my passphrase, takes me only a couple of seconds.
I’m certainly not the first to come up with the idea of managing password with Vim. These resources were particularly useful to me when I was researching the possibilities:
If you’re interesting in other ideas for password management, password-store and KeePassC are both neat projects that I follow.
2013 June 30: larsks has hacked together a Python script to convert KeepassX XML exports to the plain-text markup format that I use.
I’m new enough to bicycle touring that it holds a certain novelty which is lost to me with backpacking. Last week’s 4-day trip is the longest I’ve completed on a bike. Much of the skills and gear crosses over from backpacking to bicycle touring, but there are some differences.
When backpacking, any extra weight is noticeable but I rarely fill my pack. On the bike I find that I’m much more concerned about bulk than weight. A few extra ounces – or even a pound – of weight makes no difference to me when riding a bike, but I do always fill my bags.
Bikepacking bags make sense and I’m a firm proponent of their use. Using them exclusively, without a rack, seems silly to me. A bike without a rack is like a pack without a frame. It may save a small amount of weight, but the trade-off is an unnecessary limitation on your carrying ability.
Last week’s tour was the first in which I used panniers to supplement the bikepacking luggage. I opted for a small set (custom built by a local company) that are actually intended as front panniers. The smaller size was much more appropriate for my needs than standard sized rear panniers. I foresee them being used on all future trips.
A couple weeks ago I swapped out my crank. My old crank had the standard 30/42/52 gearing that you’ll find on most road triples. When you stop to think about it, it isn’t a very practical combination. I swapped it for a Sugino XD-600 with 26/36/48 chainrings. Paired with my 11-32 9-speed cassette, this has proven itself to be perfect. On my commute I can race along in the 48-tooth ring, smoking latex-clad roadies. When confronted with mountains on a loaded bike I can drop down to the 26-tooth ring and spin merrily to the top.
I feel like I have a pretty decent grasp on most of the backcountry around here thanks to travel on foot. My bike is allowing me to build a similar mental map of the backroads. And the eating is better.
Even if your night’s shelter is uncertain
and your goal still far away
know that there doesn’t exist
a road without an end —
don’t be sad
In the essay he introduces the website and describes his experience as a user purchasing illegal drugs. It is well worth the read. I’ve spent hours on his website perusing his other works.
Published in 1983, the book paints an inspiring picture of the Swiss Army and Switzerland’s strategy of defense – the Swiss “aptitude for war”. They have combined their country’s topographic barriers with careful planning to “prevent war with a price of entry that is too high.” McPhee calls it the “Porcupine Principle”.
To interrupt the unity of bridges, tunnels, highways, railroads, Switzerland has established three thousand points of demolition. That is the number officially printed. It has been suggested to me that to approximate a true figure a reader ought to multiple by two. Where a highway bridge crosses a railroad, a segment of the bridge is programmed to drop on the railroad. Primacord fuses are built into the bridge. Hidden artillery is in place on either side, set to prevent the enemy from clearing or repairing the damage. All purposes included, concealed and stationary artillery probably number upward of twelve thousand guns… Every railroad and highway tunnel has been prepared to pinch shut explosively. Nearby mountains have been made so porous that whole divisions can fit inside them. There are weapons and soldiers under barns. There are cannons inside pretty houses. Where Swiss highways happen to run on narrow ground between the edges of lakes and the bottoms of cliffs, man-made rockslides area ready to slide.
Simple chat provides asynchronous communications in distributed, low-bandwidth environments. (It also lends itself to resilient transport.) They’re working on moving to XMPP.
The book is an account of the author’s 3 year, 30,000 mile bike ride from Siberia to England via Australia.