i’ve used `pass` for 4-ish years now. i stopped last month. the interactions between pass and gpg-agent are too opaque for someone who’s not a regular PGP user. what happens when i let my PGP key expire? what’s the right way to share passwords between multiple machines — can i just clone the ~/.gnupg folder, do i need to `export` and then `import` the keys? should i create subkeys for each machine?
i want my password manager to be decently transparent, because if i misunderstand its failure modes that’s a big deal.
anyway, i’m using SOPS now [1]. it comes with a different set of tradeoffs (doesn’t integrate with keyrings quite as well as GPG does), but it’s way more transparent and pluggable. i generate distinct pubkey/privkey pairs per logical user and i can grant any subset of keys access to specific secrets. so e.g. my desktop and laptop can decrypt my banking secrets, but my phone cannot. i have a nightly backup cronjob which has to run unattended: i encode my Backblaze API key to the `duplicity` user’s privkey, and can safely check the encoded key into public repos and such. it’s simple and easy to grok. more so than pass, IMHO.
Yes you just clone the folder and that's it... I've moved machines several times and this "just works". I think you're making a big mistake leaving pass :). pass is just a UX for PGP. PGP enables a lot more. Learn one and it enables a lot of other things...! As you've been able to see.
well i think you have to launch gpg-agent and such too. and what channel do the two use to communicate with eachother? do you need PAM configured and running? i was trapped in my initrd earlier, desperately wanting to access my passwords, and when i ran `pass <path/to/file>` it... failed. some "can't connect to gpg-agent" message or something. so then i had to figure out how to interact directly with the GPG utilities.
`gpg --decrypt <path/to/.pass/word> --gpg-private-key <path/to/.gnupg/privkeys>` (my rough recollection) was giving me obscure errors. i stumbled across some random stack overflow post telling me to use `--pinentry-mode=loopback`: i guess it wanted to show me a x11 prompt and couldn't because X wasn't running? or maybe it was some PAM thing? idk. reading passwords off an unbootable system is a super edgecase but somebody you'll find yourself in an unexpected situation and you _really don't want to have to worry about how to get out of it_ when it comes to something as critical as a password database.
if you know the ins and outs of GPG, you're probably fine. if you don't, something with fewer interactions might make more sense.
You can't encrypt new passwords to it, but you can still read old ones that are encrypted to it.
> what’s the right way to share passwords between multiple machines — can i just clone the ~/.gnupg folder, do i need to `export` and then `import` the keys? should i create subkeys for each machine?
if the keys are on a hardware smartcard like a Yubikey, I just reuse the key. if not, I use separate keys for separate hosts and encrypt my pass secrets to all of them using the .gpg-id files
> anyway, i’m using SOPS now
I think SOPS is awesome, too! it's my favorite way to securely store secrets in IaC projects
Just add any second or third (sub)key to .gpg-id inside the password-store dir. I use pass with two separate gpg sub-keys loaded on 2 separate Yubi keys. To unlock passwords, I must have one of the yubikey or my backup master key that's on a encrypted usb. It also works over ssh without cloning the pass repo to a separate machine.
I use multiple keys for encrypting the secrets. It's been going fine for about 5 years and at least two key rotation events.
I usually have a key for each device that requires access, sometimes they overlap for all secrets and sometimes they only have access to specific folders (think a work vs. personal separation).
It's a high friction environment for sure, but I'm happy with it.
Imho, plain text is the optimal way to store passwords and related meta data. Before pass became popular I started with my own 'plain text pw store', while converting from some db backed $PWSTORE, which became obsolete. So now I'm happy to have it all in a single text file with some markup around. Editing is done with some vim settings like folding, not showing passwords and pushing entries to the clipboard.
And here lies the difference. What I was not able to do this with pass: I think I use xclip, which detects if the clipboard was used, after which the pw is removed from the clipboard. No timeout. This enabled me to consecutively send a list of strings to the clipboard. E.g 1. Send URL, 2. Username, 3. Secret. Recently, I added TOTP support.
I think pass is not able to do this. I would like to convert over to pass, but my established workflow is to convenient. Well, I haven't checked all the extensions of pass though. Otoh, I would not like to write an extension of my own.
I'm pretty sure `pass edit foo` does more or less what you seek: it launches $EDITOR with the full contents of whatever's in foo, and would therefore naturally support whatever markup or editor shenanigans you want for your preferred workflow. Or `pass show foo`, which you could pipe any which way for whatever processing you see fit.
I even have my wife set up with the android app just in case something happens to me or she needs common passwords. She doesn't use it for her passwords yet, but baby steps.
I was, recently, very happy to switch entirely to KeepassXC, which for me has all the features mentioned here. Most importantly, it serves as my SSH-agent and Sercret-Service, getting rid of the Gnome Keyring.
I was currently looking at how to use it as a secret storage in CLI version or with kpcli.
But discovering PASS, PASSAGE and SOPS, I'm now very interested in these file-based and modular solutions, more like plain text and future proof.
The big concern would be that I will have to put back the Gnome Keyring for the Secret-Service... Big NOPE.
Do anyone know a solution for that with SOPS or PASS?
The linked attacks are literally not applicable to the "pass" pass use case. Even if they were there is no authentication done in the pass case. An attacker could replace the whole file so they don't have to mess around with trying to modify the encrypted material. An attacker could just delete the whole file as well for the same effect. So that doesn't really matter for the password storage case. This suggests that the author has not yet entirely thought through the password storage case.
>For a more in-depth post on the maladies of PGP see What’s the matter with PGP?[1].
It is unclear why the link to this blog post was posted. It seems to have nothing to do with what "pass" does. Anyway, here is my standard critique of that article:
> An attacker could replace the whole file so they don't have to mess around with trying to modify the encrypted material.
Replacing is one way of modifying. If the passwords storage is authenticated, it can't be replaced.
(An attacker could probably replace the storage with its older version. Unless there's an extra mechanism in place to counter that — this highly depends on the concrete setting.)
You still get the regular PGP integrity protection even in a case where there is no authentication. I just tried it and pass just sent along the GPG error:
gpg: WARNING: encrypted message has been manipulated!
It's still very unclear (having spent a few minutes on the RFC) what it does exactly. It sounds like a mechanism to detect accidental errors (say, user copy-pasting encrypted data incorrectly or passing some garbage in place of ciphertext) and not maliciously crafted modifications. More like error correcting code than authentication.
The fact that it detects one byte being modified means nothing.
In the case of pass, no authentication is normally done, so what remains has to be an integrity check. Pass can sign git commits, but OpenPGP signs the content directly, so the MDC is not used.
The encryption mode normally used in OpenPGP is an improved version of cipher feedback (OCFB) for the block mode and something called the modification detection code (MDC) to detect modification. The two (OCFB-MDC) work together to produce an authenticated encryption mode based on shared knowledge of the symmetrical encryption key. In practice few seem to bother with the MDC but it is there and is cryptographically strong should an implementer want to use it for preventing, say, EFAIL.
I give this article a chance, but some assumptions are outright false. For example:
> No Post-Quantum security
Yeah, no. The beauty of PGP is being able to select your encryption algorithm. Somehow, arguing that AES-256 is more resistant to for example Ed25519 is just factually incorrect and people that use KeePass are not memorizing 40 character passwords to unlock their password manager.
> No Service Privacy / Leaks Changes
Pass doesn't make assumptions. If you want to encrypt filenames then wrap it with gocryptfs or cryfs or pass-tomb. The nice thing about syncing with pass is having auditable changes that doesn't require a complete database resync. Imagine someone modifying your password store with KeePass. You are not going to have diff to tell what has been changed. With Password Store, you can see exactly what has been changed between syncs.
> No authentication of values
Again, something that you can change in your PGP settings. I'm not going through the full article, but in all honesty it just sounds like this person doesn't like GnuPG and doesn't understand it. Lest not forget that pass is by the same individual that created wireguard and a slew of other security-focused tools and I think their reputation speaks for itself.
The use of age doesn't seem to address any of the stuff in the linked article. At least the use of age would not make things worse in this particular application because pass does not authenticate the saved password files. Age famously can't do authorization for the asymmetrical encryption case.
Fair, but I think that is more of an exception than the norm. For people that may want to more frequently lock their password database, having a 40 character password would quickly become a PITA.
And you only have to unlock it perhaps once at the beginning of the work day (set auto-lock/forget to 8 hours), or twice a day (morning, after lunch; auto-lock to 4 hours). Once unlocked maybe only ask for confirmation for use.
Using a phrase in a book or a poem is not much stronger than using a single word as a passphrase. Attackers include such phrases in their cracking dictionaries, including variations on spelling and punctuation. After the initial hashing of the candidate passphrase, a five-letter word takes exactly as long as a 100-character lyric from a song.
There are lots of sad stories of people losing funds in the early days of Bitcoin when "brain wallets" were briefly popular. Victims used quote-based passphrases that seemed unguessable.
The threat model is a little different when it includes getting access to your encrypted password-manager database or OpenPGP smart card. But the point stands that a well-known phrase might as well be a dictionary word.
To me it makes more sense to use a longer password for FDE, and maybe have it have it cached into the TPM but with a shorter unlock code for resuming, locking, etc. It might make sense to have a two tier password for password managers though. Like a hot/cold.
Using a dictionary, I was able to roll a funny and easy to remember Passphrase that fulfills the 40 character limit. I'm using it ever since for my KeePass file.
I mean, if the attacker has writable access to your vault, he likely can observe you handling the unencrypted password or steal all your gpg key material after you unlocked it. This makes the "No binding between keys/values", "No authentication of values" and "My passwords are emails?" sections moot.
>I mean, if the attacker has writable access to your vault, he likely can observe you handling the unencrypted password or steal all your gpg key material after you unlocked it.
To be clear here, only if that implies access to the memory you control, otherwise, no. GPG is pretty good about local file access by an attacker and pass maintains that on platforms where that is possible.
Access to the vault ≠ access to unlocked vault. This is the whole point of storing anything encrypted on your disk.
The password managers don't protect against a malware running on your laptop with root privileges and attaching to your processes. They protect against someone taking the disk out of your computer and trying to extract the passwords.
But if they have the disk and modify is, its still them who have the disk. So the "No binding between keys/values" and "No authentication of values" still dont work out, either. And they are able to modify the contents on my disk, they'd be easier off installing a rootkit, pass cant protect against that.
Based on git and gpg. So a *ix programmer has full control and full history. And you can move git bundles to offline systems.
We used it also as a poor man's vault in a small company, you can have different keys in different directories, not giving everybody access to everything.
The only issue i found myself having using stuff like this is syncing to my mobile phone. Currently i am very satisfied with bitwarden due to their firefox extension and mobile ios app which integrates with the ios keychain. Pass sadly isnt usable for me.
I think the GP is aware of that, and just decided it's too much of a hassle.
I used pass for few years, and have recently switched to bitwarden. I know my way around git well, but I just never remembered to push the new passwords from either my desktop or my phone, which sometimes made me reset the password on one of the devices, and getting conflicts later on, I was always forgetting the password to the SSH key on my phone, and was ever-worried that I don't understand shit about GPG. Two years ago I switched my laptops, and moving the password store to the new one was painful. I'm sure I did something wrong, and that someone who knows what they're doing would have no trouble doing that, but I guess it's not for me.
Also, a minor pain point is that generating a new password for an existing login overwrites the whole file, and not only the first line, so I had to copy the other login data from the old file to the new one. I'm sure there's a way around that, but I never bothered.
You can use the integrated git feature to sync passwords between all sorts of devices. The nice thing is, that there are pass clients for almost every system including iOS, Android and Windows and with git you simply pull changes in. And by using your own server, you don't have to rely on the security of others to keep your secrets safe.
I switched from pass to KeePassXC/Keepass2Android (with my .kdbx file living in OneDrive). It’s a much more convenient experience on all platforms. Transparent sync via OneDrive, simple self-contained files and apps, no git and no PGP to mess around with, convenient browser integrations, support for auto-type including working with the the idiotic partial-password thing one of my banks does. pass might be fine if you’re only working with Linux/macOS boxes (although I’d still consider it easy to mess up). If you’re also using Windows, then pass is much less convenient. On Android, the setup with Android-Password-Store and OpenKeychain was pretty fragile and annoying last time I used it.
Pass is a fascinating project. Can't praise it enough. I've been using pass for eternity and have a big chunk of automation regarding passwords/token/keys for my hobby and work projects. For example I use pass to store TOTP secrets and get a PIN in a sane way. Or use pass to store ansible vault password with ANSIBLE_VAULT_PASSWORD_FILE and a little script to insert password automatically during playbooks runs. Also our CI's numerous automation scripts handle PASS_FILE environ variable to get creds from a pass.
Oh man, I unironically love ed. That was such a clever thing at the time. It's really nice to understand it too, to put the rest in its historical context.
AFAICT pass just calls out to gpg; so the answer to your question is, "It does whatever a bare gpg command would do". If you have gpg (or more specifically, gpg-agent) configured to ask for a password every time, using pass will require you to enter in your password every time; if you have gpg-agent configured not to ask within an hour of the previous password, using pass will cause you not to have to enter the password more than once an hour.
And of course, if you've just entered your gpg password to decrypt an email with GPGMail (Mac Mail PGP plug-in), you won't have to enter your password to decrypt a password, since they're both using gpg behind the scenes.
It doesn't (and can't) really address the most important issue that there's no secure clipboard and on top of that some desktop environments come with "clipboard history" malware by default that sniffs your clipboard and logs its content to an unencrypted file.
You needn't use the clipboard feature, and in fact I think I can count how often I've used it on my fingers after several years.
My browser has a pass-compatible agent that requests passwords for web sites when I tell it to do that, if I just want to know an actual human password that's in pass, I run it on the command line and look at my terminal. In my home the visual displays are not recorded ("for training and quality purposes").
https://news.ycombinator.com/item?id=29577272