This is the process I use for password management. Thought it might be valuable to get the details written down in case that bus that's going around cleaning up sys-admins has another stop.
Priorities
So, you know how GPG is a smidge controversial? What with the suboptimal defaults and occasional vulnerabilities...
Well, what if we just ignored all of that because our priority was longevity.
GPG isn't going anywhere. I suspect that we will still be able to run it in one way or another for the next 20 years (assuming there are still people by then). So if your concern is state of the art post-quantum encryption then great, there are other options, but if you're looking for boring, stable and sedentary, then maybe GPG is the three-legged horse for you!
Paw
So I wrote Paw. It is yet another password manager. This article isn't an ad, you probably shouldn't actually use Paw. But it pokes tiny little needles into my particular itches:
- It stores GPG encrypted password files on your private server
- Transfers your secrets (without actually copying files) via ssh and pipes
- Decrypts the remote secrets and loads them into the local copy-paste buffer
- Allows you to keyword search the password store without needing to decrypt anything first
- Caches the decryption password for a specified duration
Demo
Paw sends shell commands over ssh to search for the password you need. Let's
make ssh stop prompting for passphrases (for a short while).
# start ssh-agent with an authentication timeout of (eg) 12 hours # add your ssh key into the agent # You'll get prompted with the instruction to create or search credentials # Let's create a new credential, by entering the text "new" # It tells you what file it's going to create # Enter the username for the credential # Enter the password (it'll use apg to display an example) # There's an extra field for a secondary secret # Give it some keywords, so you can search for it in future # And then enter a GPG encryption password # And paw will write it in ascii armoured encrypted text on the remote host # Note the searchable keywords are not stored encrypted # this makes searching fast since we only decrypt what we need
Start Paw by pointing it at a remote host and remote path where the passwords
will live.
Reduce ssh friction
Let's take a look at what was actually created:
paw
$ paw my-secret-host:/path/to/passwords
Now let's search for the credential. The search makes use of the keywords we
entered that are stored in GPG's plaintext "comment" field.
my-secret-host:/path/to/passwords/23.asc
If it finds any matches, then the final match is decrypted and the contents pushed into your local copy-paste buffers. It does this:
- Without copying the files between your local server and the remote server
- Without modifying the files on the remote server
- Without leaving behind decrypted copies of the data anywhere
The copy-paste commands support xclip (Linux default), wl-copy (Wayland), and
pbcopy (MacOS). The xclip default allows only three pastes before the contents
are wiped.
# Let's search for the keyword "login" # Oops not specific enough, it loaded up the hotmail login by accident # Let's search on "gmail" instead
Now the username (printed above) just got automatically loaded into the
"primary" buffer and the password (not printed above) got loaded into the
"clipboard" buffer.
Search for a credential
The primary (username) buffer can be pasted on linux using middle-click. The clipboard (password) buffer can be pasted using ctrl-v.
Symmetric vs Asymmetric
No web interface or mischievous GUI. No opaque storage locations or file formats. Just one centralized store of GPG encrypted files, wherever you want them to be, that can only be accessed via ssh and decrypted with a password...
Er yes, password. The files are encrypted using symmetric encryption instead of GPG keys. I've outlined the reasons over on the github page, but essentially it boils down to accessibility.
I understand the value of public/private asymmetric encryption, but here are my thoughts for just this specific context:
- Over the years it seems likely that one will misplace, or inadvertently leak their private key file. Depending on your level of preparedness, it might be an unrecoverable situation
- Sadly, through convenience, my private GPG keys will almost certainly end up existing on multiple laptops and servers. I'll lose track of them. (It's very conceivable that any new devices will need access to a password!)
- A passphrase for a GPG key will still need to be stored by some mechanism (and don't say: "the password manager")
- GPG keyrings and the importing and exporting of keys, and specifying recipients is juuust difficult enough...
- And most importantly to me: the use of GPG keys will make it harder to transfer the ability to decrypt, to my family members
Passwords also have their obvious weaknesses, but "losing them" isn't something that's in my DNA. I like that they can be written down. Put in a will. Or intentionally shared with ease.
National security
My concerns are not ones of national security. I am prioritizing long-term access over long-term safety insofar as the encryption goes.
As far as ssh access goes: it's intended to be a rock solid network barrier, that is intentionally circumventable given physical access to the hardware.
My hope is that this will provide my family with a skerrick of a chance to access my accounts (if need be) in the unforseeable future. And in the meantime, I quite like having private centralized access to my passwords, without depending on another fucking company.