While they're real, most of these issues don't really seem worth worrying about except for the site names not being encrypted, but pass also isn't a cloud service so I'm not convinced that's a big deal?

I guess it's an issue if you're storing the repository in github or backing it up without additional encryption, but I suspect that's not how most people are using it anyway.

As long as you understand its limitations pass is nice precisely because it's simple and basically just a wrapper around git + gnupg.

In comparison, most cloud password managers don't have these specific issues, but they are also very likely less secure in other ways.

The KeePass format has been around for years. I don't really understand why people keep using pass, or why it bills itself as the "standard" Unix password manager.

There are also already command line KeePass utilities, like passhole [0] (mine) and keepassxc-cli.

[0]: https://github.com/evidlo/passhole [1]: https://keepassxc.org/docs/KeePassXC_UserGuide.html

Yeah, yeah, but if an adversary can do things like

> replace the contents of ./Personal/malicious-site.com with the contents of ./Work/id_ed25519

then it's pretty much game over anyway.

I know it's not FOSS but 1Password does have a decently fully-featured CLI client

https://developer.1password.com/docs/cli/

All designs have use cases and scenarios for which they are better or worse.

Pass (and gopass, and all the derivatives of the same idea) is not the best personal password store (for that KeePassXC and similars might be better) but coupled with git gives a technical team a way to share passwords in a more or less secure way on rest.

AFAIK KeePassXC don't give a way of automating merge of different versions of the password store (for that the granularity provided by git and the pass format is better), so modifying the keys by a team is an exercise of coordination, and have one global master key that implies an all-or-nothing approach.

And being built over time tested technology in a simple enough way is another feature. It is a simple bash script taking advantage of gpg and git, not a complex piece of software that should be audited with each security update.

Of course that the computers taking part should be trusted, if the personal computer of any of the people with access to the keys is compromised, or where you store your git repository, it might not be so safe, but probably you should worry about bigger problems.

This attack makes no sense to me:

—————

Active Attack:

1. Adversary replaces the contents of ./Personal/malicious-site.com with the contents of ./Work/id_ed25519

2. Victim decrypts ./Personal/malicious-site.com and the decrypted contents is placed in her clipboard automatically.

3. Victim logs into malicious-site.com.

The victim just uploaded her work SSH private key to malicious-site.com

————

If the attacker is on the victim’s machine and has access to the ssh private key (“id_ed25519”), wouldn’t they just upload it directly to malicious-site.com via curl or whatever? Why this whole rigamarole?

If someone is on your machine doing arbitrary things what software can reasonably protect you? Even Signal would fail.

I've never understood the "complexity" of PGP/GNuPG. Granted the man page is dozens of pages long, but I find it no more complicated than any other command line tool. Maybe it is because I have used it professionally and personally forever.

The author of Age has ported Pass to use Age as the encryption scheme if one needs a modern solution.

As for reading the directory structure, you don't have to put your passwords in a directory structure and just do security by obscurity.... But, if some has access to my local machine, I have bigger issues.

I like the command line capabilities of "pass", and I also agree with the author about some of its security issues and complexity.

I created "passable" to do what I believe is a bit better (IMHO) for command line usage: symmetric encryption, and files do not use any particular in-the-clear directory structure.

The code is POSIX shell, short,and easy to audit. MIT & Apache & GPL license. Constructive feedback welcome.

https://github.com/SixArm/passable

> 90ties horror show

I had to briefly pause reading there, as the word "90ties" is a horror show itself.

Ninety-ties? Ninetittys?

Anything PGP based is disqualified usually because of decrypting to the hard disk. This means that an attacker that can read files at the right moment can access the decrypted file. pass thankfully uses /dev/shm so you don't have to worry about the password making it to the unallocated parts of your hard disk where it can be read out via hardware access, so it needs to be an active attack, but still.

The bigger issue with pass, IMO, is that there's no audit trail on secret access. At a previous job, the team used pass for shared ssh keys, passwords, etc. One developer got malware on their workstation. It was detected fairly quickly, but not before he'd used pass once or twice. At that point, we had to assume that the malware had been able to capture the PGP key and all the encrypted secrets. That meant that we had to rotate every single secret in all of our systems that were reachable from those. In a better setup with something like Hashicorp Vault, GCP Secrets Manager, etc, with auditing, we could've looked through audit logs to see which secrets were actually accessed during the vulnerable window and only had to rotate those.

>RSA (and all other public key crypto systems supported by PGP) will be broken by Shor’s algorithm

Seems there's work going towards, or at least the idea is being explored, adding PQC to OpenPGP.

https://www.ietf.org/id/draft-wussler-openpgp-pqc-00.html

https://datatracker.ietf.org/meeting/113/materials/slides-11...

>If you insist on using Pass, I highly recommend using a separate PGP key just for Pass.

Will guess that's how most people use it already. Separating keys for usage is afterall something core in PGP.

If someone modifies your PGP encrypted password file and you decrypt it GPG will say:

    gpg: WARNING: encrypted message has been manipulated!

... and GPG will return a fatal error. So the meandering stuff about the malleability of PGP is not of any practical interest. The underlying cryptography that insures the integrity here has stood the test of time (over 20 years at this point).

In another part of the article it is mentioned that an attacker can entirely replace a particular password file ("No authentication of values") which makes the PGP malleability stuff irrelevant. So we are maximizing the number of listed issues here. Note that pass will sign the password files if configured to do so which makes this issue go away.

I feel like half of these problems would be solved by pass signing and encrypting the stored passwords, and then refusing to decrypt anything not signed by a known-valid key without the user's explicit case-by-case consent and knowledge.

I am researching password books at the moment https://passwordbook.org/7-benefits-of-using-a-password-book...

The discussion in the article is poor.

* Yes, symmetric encryption is better than the asymmetric encryption in terms of resistance to brute force attacks. However, as soon as you type in the password in a login page, it will be protected by an asymmetric encryption in TLS. All data in transit is protected by asymmetric encryption, often RSA 2048.

On the other hand, asymmetric encryption is better than symmetric encryption in that it doesn’t need the private key for encrypting a password. This reduces the exposure of the private key.

* The fact that the file names may not be encrypted is part of the appeal. In exchange, you get: passwords live in sort of their own sandbox environments. If the local machine is compromised, while a password is read, other passwords are not affected (see the next item on smart cards).

This is great: with a single-database, as you frequently extract unimportant passwords, your important passwords, say your bank account password, is decrypted too, and at risk. Further, with a single database, it’s difficult to frequently type in the master password; so the database is usually unlocked in local machine, with all passwords loaded in RAM.

* A GPG key can be put in a smart card. Every touch of the Yubikey gives up only one password.

* There are many password managers with self- rolled cryptography. The code has very rarely been audited, even for keepassxc. A lot of code is involved, with GUIs, complex databases, apps, and plug-ins. You want to outsource the cryptography to a well audited codebase. OpenPGP and GPG have been throughly reviewed.

Pass is a simple short bash script that you can actually audit it yourself. That’s very important to security.

* The directory can be encrypted by a wrapper, see gopass and similar.

* GPG 2.3 has introduced AEAD modes, such as ChaCha-Poly. So there is now authenticated encryption (there is MDC which is outdated). You could also sign the encryption, which is a proper authentication.

There are also newer tools such as Passage using Age encryption (though some tools such as agent is missing). Passage uses PIV applet of the Yubikey, so you can have multiple keys.

* Symmeyric encryption allows for 256 bits of security. In practice, it’s difficult to frequently type in and rotate such key. People use much weaker passwords. You can use a key file, but that’s plaintext in local system.

* The secrets have to be entered by command line a lot of times. Pass works great with piping etc.

I strongly suggest using a Yubikey with Pass or passage. You get strong security conveniently with a weak PIN code.

I wonder what OP would think of this password manager recently mentioned on HN? https://news.ycombinator.com/item?id=34159631

Is a better alternative to store passwords in an encrypted SQLite database? That would address the problems with the directory structure and Git.

Just use KeePass. It allows you to encrypt with a key, if that's your thing.

Edit: just noticed they recommend KeePass at the end. Damn I'm good.

>...there is MDC which is outdated...

My understanding is that the current authenticated mode (what I like to call OCFB-MDC for OpenPGP Cipher Feed Back, Modification Detection Code) is secure. There is no evidence that the proposed authenticated modes are any better, other than perhaps for higher performance in the case of OCB mode. I wrote a rambling editorial about the idea that the current mode should be replaced:

* https://articles.59.ca/doku.php?id=pgpfan:no_new_ae