colin's blog

Posted Mon 05 February 2018

Vault and Personal Secrets

I use Hasicorp's wonderful Vault tool to manage my personal secrets. I realize there are a lot of services out there at this point like 1Password or Lastpass that can seal up your personal information in a secure place and give you token-ized access to it. But that has always left a bad taste in my mouth. I refuse to trade simplicity and ease of use for control and knowledge of the system. There's nothing but the fear of bad PR between Lastpass and creeping bad IT practices inside the corporation. And the fact that their tech stack is not open source means all you have is a wing and prayer they're doing the right thing.

In the meantime, Vault provides an eminently audit-able, single binary application that can handle seriously complex use cases, as well as more pedestrian ones. What follows is not a tutorial on setting up for your multi-user organization (though I've done that too), but rather a few pointers if you want to use Vault on an individual level.

First off, acknowledge that for your use case, high availability (HA) is not necessary. When an org talks about HA, they mean six 9's or something like that. Personally, for my password manager, I can probably get by with it being up 90% of the time, as much like my car, my actual utilization of a password manager is more like 10% of my day. To that end, I'm going to recommend using the file backend for personal use. You can get fancy and use S3, or even setup Consul and make it truly HA. But the time invested makes no sense. What you need to make sure when you use the file backend is that you have a solid backup of the vault files. I use Tarsnap as my default backup, and also pay for DigitalOcean's droplet backup images. So I've got a few paths of recovery in the event of a disaster.

Once you've got storage down, the next question is how to use it? For starters, you'll need to keep your vault key somewhere. The nice part about Vault is that you have two primary means of accessing it, one is the root key, and the other is your user key. I keep my user key in an encrypted file on my webserver. It's not linked anywhere, so you'd have to know it existed to find it, and once you did find it you'd need access to my GPG private key and a passcode to decrypt it. In the future, 4096 bit encryption might make such publicly visible secrets safe, but for now, I'm a pretty low value target and the tech is still pretty slow.

Next, I keep my sealant keys and my root key safe in an encrypted file on a personal installation of Nextcloud. Honestly, you could keep this in Dropbox or something similar too. Anything that provides fairly easy duplication across multiple hosts and easy access in the event you need to unseal your vault, or refresh your user key.

Finally, on a day to day basis, my vault key lives only on the webserver encrypted, and in my environment variable of my shell. I use keybase to automate decrypting the stored file whenever I open a terminal, and that gives me command line access to my passwords. A simple bash aliases give me easy commands like getpass, which reads an entry from the secret endpoint in Vault and copies it to the clipboard. From there I can enter it on forms, or enter it in the command line.

The real hallmark of a secret management system should be how easy it is to revoke access in the case of a breech. Between expiring a user token and generating a new one, and access to timestamps for when each password was entered, it becomes trivial to re-key or systematically refresh passwords stored.

Category: Tech
Tags: security passwords vault