Posted by Bogdanp 9/13/2025
* Your secret key can be stored in Yubikey, handled by a dedicated OpenPGP agent. This allows deriving a strong key from a weak one. Your password is basically a short PIN with max 3 tries. Every password retrieval can require a physical touch. This is convenient and secure!
Pass makes sense if you use it with a hardware key, with touch enabled. With this setup, it’s hard to beat its security.
* It uses public key cryptography, and comes with its advantages. You don’t need your master password to add/encrypt passwords. You only need that for decryption. Less exposure of master key, and more convenience.
For that reason, it’s well suited to share passwords with other people or devices. You can encrypt to multiple public keys. This adds multi user and device support.
You can easily add a backup offline public key (which you may print) if you lose your Yubikey.
* You can decrypt a single password without decrypting and exposing other passwords. The passwords are isolated, if you use Yubikey.
* Searching passwords is quick and transparent. You easily see what is in your store.
* You can use it programmatically, eg, your backup script can grab a password from the store.
* It’s a short bash script that you can verify, and delegates encryption to a dedicated well-audited cryptographic tool.
* PGP is a standard, and GPG and git are widely available. There is no database to break or migrate. You can read your passwords anywhere and in the future.
* The script is written by the creator of the acclaimed Wireguard!
There are also cons.
* Some people don’t like that it leaks metadata (filenames, and password tree), though there are versions of pass that fix it.
* Lately gpg is causing some troubles with Debian Trixie. GPG agent frequently locks the Yubikey and requires restarting pcscd (probably due to conflicts with pcscd). There is a similar tool Passage using Age, maybe that solves it.
* There are mobile apps, but they are not as frequently updated as something like Bitwarden apps (which has client for every OS, and frequently fixes bugs and adds functionality).
* I haven’t used and not sure how good browser support is.
Here is a post on a similar password management with GPG replaced with Age
That is also nice since I have ssh already set up so syncing to my computer from the phone will be easy.
https://github.com/drduh/YubiKey-Guide
This guide covers many adjacent topics; the relevant part is generating the secret key inside Yubikey, or in an airgapped system and doing “key-to-card” in gpg.
Granted on the desktop I find using a (qt especially) GUI more invasive than a terminal but at least on the Android side the app is quite good.
The one major downside to it is that it is absolutely unusable for sharing passwords because obviously that would require sharing my passphrase, and there is no way to “store” a password that someone else set. I’ve thought about writing a mode that would encrypt a string (eg a shared password) with the metadata-generated password and store it in a separate piece of metadata for that purpose, but the number of times I’ve needed that has been extremely small.
However, once you introduce metadata (e.g., to deal with password rules), the idea loses most of its appeal. I wouldn't feel any more comfortable posting such a thing publicly than I would a vault.
What could be considered more sensitive, if you cared, is usernames. Someone looking at my metadata would learn my hn username, for example. But I don’t really consider that “secret” info.
Initially I didn't get it, then I realized that it was using the deterministic password generation approach.
Offtopic: SECUSO has a really nice collection of open source apps.
Each password file is AES-encrypted with my master password.
I copy the whole vault around between machines with rsync.
When I run 'password bank' a shell script searches ~/private/Passwords for files that contain ‘bank’ and offers a menu, then gpg-decrypts the file I selected.
I also use this for scans of my passport, recording my bank account numbers, and anything else I want to keep around.
I thought I was the only one, and now I've found out there are thousands of us!
But a life saver is using it with <https://github.com/skeeto/passphrase2pgp>.
This means we don't need to move gpg/ssh keys we can just recreate them by remembering their passphrase (and other stuff like the date if we want).
# gpg key for the encryption of the password-store
passphrase2pgp --subkey --protect=2 --uid "helloworld" | gpg --import
#for access to the git remote repo add to it this public key :
passphrase2pgp -u emergency -f ssh -p > ~/.ssh/emergency.pub
#only use it to install a non-emergency key as a new authorized key :
passphrase2pgp -u emergency -f ssh | ssh-add -
Funnily enough I never used `pass generate` once, even tough I have more than 3700 passwords. I always used the `pwgen` command, I don't know if there really is a big difference between the 2 (except pass generate being already in pass).
As for how to structure, here are some example of how I do it :
<service>/email
<service>/otp
work/<service>/password
homelab/<service>/username
Then it's very easy to get the password or the otp, just bind `passmenu`, `passmenu-otp` in your window manager or directly use the command line for multiline stuff.
Pass is just a shell wrapper around gnupg, when you run pass some/secret/path, what actually happens is pass constructs and executes a gpg command (e.g., gpg --decrypt ~/.password-store/some/secret/path.gpg) and the output of gpg (the plaintext secret) is piped to pass's stdout.
Most people know this though. What I learned I didn't know before though was this:
Memory Zeroing: after it's used (e.g., copied to a pipe or stdout), GPG's internal memory management aims to zero out those memory regions used as soon as they are no longer needed
Memory Locking: GnuPG also uses mlock() (or equivalent OS-specific calls) to lock sensitive memory pages into RAM. This prevents the plaintext keys and decrypted data from being swapped out to disk, protecting against swap-file forensics or cold boot attacks.
I had been banging my head against bash trying to do those things manually, and ended up with the conclusion it was best to use pass/gpg with the following addendums (from my notes in my skeleton secure bash template):
1. Minimize secret lifetime: Use subshells, functions with local variables, and unset, disable bash history
2. Pipe secrets directly: Pass secrets via stdin or process substitution directly to the consuming program without intermediate variables if possible.
3. Rely on the tools: Use pass, gpg, or KMS CLIs that are themselves implemented in lower-level languages and can (and should) implement these memory protection techniques internally.
ps: keepassxc is the other favorite to use
https://codeberg.org/jwgarber/napa/src/branch/main/database....
> Notably, pass fails both of these requirements, ... , and the files themselves do not use authenticated encryption.
With pass you can turn authentication on by setting an option to sign the files by default. That comes at the cost of requiring an extra entry of the passphrase so most do not turn this on. Few people are concerned with the idea that an attacker might modify their passwords so they don't work. There is no real benefit to an attacker. They could just delete the files.
Even if signatures are not turned on the regular PGP integrity protection would still be in effect so in the unlikely event that an attacker changed the file an error would be generated and presumably passed on to the user.
That article is fairly rough. For one thing it references "The PGP Problem":
* https://articles.59.ca/doku.php?id=pgpfan:tpp
For another thing it references "the quantum threat against cryptography" as an actual argument against password store.
For the rebuttal you posted, I'll respond to one thing:
> The entire rant is basically about how OpenPGP is old and therefore bad and how new things, sometimes only vaguely defined, are good. So let's address this first.
> If someone, while trying to sell you some high security mechanical system, told you that the system had remained unbreached for the last 20 years you would take that as a compelling argument. You would be unlikely to demand a newer design. Normally old designs that have stood the test of time are valued. Cryptography is based on mathematical/logical principles. Such principles don't age out on any sort of a schedule and are valued in some cases for thousands of years.
The "unbreached for the last 20 years" conclusion about mechanical security systems does not immediately apply to mathematical ones, and we can indeed see that it is empirically incorrect. The cryptographic world is littered with the corpses of cryptographic algorithms that were secure for decades and are now broken (MD5, SHA1, DES, small RSA keys, TLS 1.0), and their C implementations that had horrible vulnerabilities (HeartBleed, etc). Mathematical proofs will not help us here either, since e.g. there is no proof that GPG is IND-CCA. (Which is unlike new systems, which do have proofs!) GPG had its day, and now it should be retired.
Also, the quantum threat is a reasonable one in the "store now, decrypt later" model. A lot of people presumably use git to store their password store online and would be vulnerable to this. The passwords in the files would probably not be important anymore once quantum computers are created, but any other long term data or other personal information that people store in there could be decrypted.
I don't really see the value in an attacker being able to store new passwords anyway. Besides, in order to do that they'd already have to have breached my private git server too.
What i love in particular is the combination with OpenPGP keys on a yubikey. Because of this you have two factor and more importantly, you unlock each password individually. This way an attacker can't steal your entire database of passwords even if they have full control over your computer. They can only see the passwords you unlocked. Because each password requires a physical touch on the yubikey.
With some other community favourites like keepass and bitwarden, once your database is unlocked, all the data is open..
But for now I simply don't use passkeys. It needs to be 100% open and cloud independent.
How I've been doing this is that I have 2 (sets of) backup people. The first set has access to the repo, but can't decrypt. The second set can decrypt (i.e. I have their pubkeys imported), but don't have access to the repo. I've chosen the people such that it's unlikely they collude against me, but in case something happens it's likely they'll be able to get in touch with each other.
There's also other possible approaches: e.g. instead of building a dead man's switch based on the encryption, you can build a dead man's switch based on the data. I.e. you'll use their pubkeys for encryption, but the repo itself is behind a dead man's switch.