Vault 0.3: improved settings management and private-key-based passwords

I’m happy to announce a new release of Vault, my password manager. (For background on why I’m doing this project, see the original release announcement.)

Before you install it, you need to know that the encryption used to keep your settings file safe has changed and you need to migrate. Make a backup of your .vault file, then export your settings as plaintext:

$ vault --export vault.json

Then, install the update and import your settings again:

$ npm update -g vault
$ vault --import vault.json

Your settings should now work just as before. Now onto the new features. First, Vault now supports tab-completion for options and service names under bash and zsh. Just add this to your profile:

which vault > /dev/null && . "$( vault --initpath )"

Second, you can now delete your settings easily from the command line. The following new options are available:

  • --delete SERVICE, -x SERVICE: deletes the settings for the named service
  • --delete-globals: deletes your global settings (i.e. settings created with --config and no service name)
  • --clear, -X: deletes all your settings

Finally, you can now generate passwords using your SSH private key. This works by, instead of taking a passphrase, using your private key to sign the service name, and using the result bits as input for the generator. So to generate your gmail password from your private key, run:

$ vault --key gmail

If you have multiple SSH keys you will be prompted for which one you want to use. You can save your selection like this:

$ vault --config --key

This will store the public part of the selected key in your .vault file so we can ask ssh-agent for it next time you need it.

That about covers the new features. See GitHib for full documentation. The next release I’m working on the moment involves adding a storage backend based on remotestorage, which I’ve been working on an open-source server for. This will mean you’ll be able to use your saved settings on the web, not just on the command line, using a server under your control. I am planning on rolling this out at my company and getting it suitable for team use; there’s still a way to go on that but I’m making good progress and a clear plan for where we need to get to. If you’d like early beta access to this, please let me know.

If you’ve enjoyed this article, you might enjoy my recently published book JavaScript Testing Recipes. It’s full of simple techniques for writing modular, maintainable JavaScript apps in the browser and on the server.