(In)Security of the “Pass” password manager
rot256.devWhile 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.
>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.
How are people using pass then? Do they only keep one copy of their password database on their computer? Are they manually copying loose files between their devices?
Use a VPS that uses SSH with key-based authentication, store the git tree of your passwords there. Uploading your whole password tree to a public repository is a bad idea for reasons explicitly mentioned in the article (i.e. pass does not encrypt metadata about the file/directory names, git stores all creation/modification/deletion dates and times).
"Use a VPS that uses SSH with key-based authentication, store the git tree of your passwords there."
Exactly what I told my Phillipino mother in law to protect her AOL account. I can't imagine why she doesn't do it.
What could possibly make you think that the guy who wrote pass (a git backed command line password manager) gives a shit about whether or not your "Phillipino" mother in law wants to use it?
That's a strawman. I'm neither your Phillipino mother nor ever suggested that she should be doing this.
There is nothing invalid about the observation. (not a strawman)
The intended userbase of pass is clearly not non-tech-savvy/non-security aware philipinno mothers, so your remark is irrelevant.
>Use a VPS that uses SSH with key-based authentication, store the git tree of your passwords there.
I'm not sure whether that's actually better than storing it on github (or any other professionally managed git instance). Sure, you gain some security by obscurity (because your VPS isn't a juicy target like github is), but that's about it. If the FBI is after you, they can send a letter to your VPS provider just like they can send a letter to github. I probably also expect github to do a better job at keeping their systems secure than an amateur sysadmin. In both cases the chance of getting hacked is fairly low, but the whole point of a password manager is that you don't have to rely on the storage service being secure to keep your passwords safe. If you need to rely on the storage service (eg. git server) to be not compromised for your passwords to be safe, then that kills a large benefit of using a password manager.
> If the FBI is after you, they can send a letter to your VPS provider just like they can send a letter to github.
And unless that VPS is in the US or provided by a US company, it's unlikely the FBI will get much of a useful response to that letter. Some countries' LEAs cooperate with the FBI and other American LEAs, but not all.
The VPS does not have my private GPG key, stored locally, and hence cannot use it to decrypt the passwords.
Right, but if an attacker has access to the VPS, it can pull off the various shenanigans that's described in the OP? That's the whole thesis of the article. If you have access to the underlying storage of pass (eg. the git instance if you're using git to sync everything), then you can perform some attacks. The attacks aren't catastrophic (ie. attackers being able to decrypt your passwords with no intervention), but they're still pretty bad nonetheless.
If the attacker has userspace access to my VPS or - even worse - my daily driver, then I have much bigger fish to worry about than. The attacker is then a single zero-day away from gaining root access and being able to keylog everything I input on my physical keyboard or send via SSH, at which point the issues mentioned in the article become meaningless.
Git over SSH to the Raspberry Pi.
You do not need a "hosted" git environment to keep a repo in a central location; a simple Unix account is enough.
When I used `pass`, I synced the password store between all my personal devices with Syncthing (non-centralized file syncing tool) and kept the store history with git. This worked surprisingly well and was even pleasantly usable on my phone with a third-party android app I found.
I said github, not git. You don't need to use a cloud service to use git for synchronization.
You don't, but are people really manually running "git pull" between their various devices, or are they using a (self) hosted git service? Even in the self hosted case, I wouldn't want the security of all my passwords to be dependent on my $5/month VPS not being compromised.
I believe that people do just sync got repos between machines. 5$ VPSes, Raspberry Pi's, laptops from 2009. Why not?
Also, what is there to compromise on a machine that basically runs just sshd with password authentication disabled?
> I believe that people do just sync got repos between machines. 5$ VPSes, Raspberry Pi's, laptops from 2009. Why not?
it's a pain because of NAT/port forwarding, not to mention the chore of making sure every device is up to date. You can get around the NAT/port forwarding issue by having a $5 VPS, but then you're essentially storing your password database on dropbox.
>Also, what is there to compromise on a machine that basically runs just sshd with password authentication disabled?
1. Same way that dropbox can be compromised: your account gets hacked or the provider gets hacked.
2. While I agree that a server with only sshd and auto-updates enabled would be pretty hard to compromise (foregoing the above), I doubt that's the typical setup. Most people probably have a "general purpose" VPS that they use to host all sorts of stuff, which means there's lots blindly typing in "npm install ..." or even "curl ... | sh" going on.
> it's a pain because of NAT/port forwarding
Tailscale or zerotier. It's a solved problem. You don't need to use a vps at all.
Or Syncthing
> Same way that dropbox can be compromised: your account gets hacked or the provider gets hacked.
Nope. My account on my vps is protected with a strong ssh key and password-logins disabled. Also fail2ban is set up to forever disallow ips that try failed logins. So not the same at all.
> lots blindly typing in "npm install ..." or even "curl ... | sh" going on.
Nope
> > Same way that dropbox can be compromised: your account gets hacked or the provider gets hacked.
>Nope. My account on my vps is protected with a strong ssh key and password-logins disabled. Also fail2ban is set up to forever disallow ips that try failed logins. So not the same at all.
By "account", I don't mean the account in /etc/passwd on your VPS, I mean the account with your hosting provider. That can be hacked/phished just like a dropbox account, not to mention the provider themselves getting hacked or social engineered.
The vps can be encrypted by a customer supplied key. In google compute, for example: https://cloud.google.com/compute/docs/disks/customer-supplie...
Yes, I do a git pull between my vps and various devices. Works perfectly well. But my threat model does not include 3-letter security agencies, so I'm completely ok with that. Beats having my passwords stored on the cloud controlled by XYZ company and then waking up to a news article saying that their servers were compromised. That is the threat model that I optimize for.
Yes, I am, and the server is in the house.
I periodically do a "git pull" onto an encrypted HDD that's stored at the office.
Offsite and backups outside of my normal backup procedures, in case I'm suddenly really screwed.
The PGP key is on a YubiKey, and I have an encrypted offline backup of that as well.
> except for the site names not being encrypted
I just use ctmg authored by the same guy and a simple script to open and close both. If you want, you can then throw this anywhere.
I know there are people who wrap their entire PASSWORD_STORE in another layer of encryption (ideally through the filesystem) to solve this. But it can be cumbersome to maintain wrappers.
> but pass also isn't a cloud service [...] In comparison, most cloud ... cloud cloud cloud
The authors recommends KeepassXC instead.
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
Any program that is GUI first (like keepass) cannot be the standard UNIX password manager. Furthermore, `pass` fits nicely into the philosophy of small reusable components. It is a small amount of shell scripting wrapped around two other commonly used tools: Git and GPG.
What's the percentage of end-user Unix systems with X installed?
What's the percentage of end-user Unix systems with Git installed?
What's the percentage of KeePass stores that can be used without X?
What's the percentage of pass stores that can be used without Git?
1. Without knowing exactly what counts as an "end-user", 15%. This is low for two reasons, 1) because I can SSH into a plethora of non-graphical systems, which I assume are the majority; and 2) just to be difficult and pedantic with the new Wayland systems for example.
2. Should be like 95% ;)
3. Without ever having used KeePass, I'm quite confident of the answer to this one... 100%. Is it officially supported and easy though?
4. Also 100%! But not happily.
Sorry, without some additional context I can't really give you satisfying answers I fear.
> Any program that is GUI first (like keepass) cannot be the standard UNIX password manager.
Why is that? Unix != lack of UI (NeXT, Solaris, any Unix descendant with a port of CDE), and being GUI first doesn't matter if there is good CLI support.
>why it bills itself as the "standard" Unix password manager
It's a smallish (<1k loc) wrapper script around GPG, a tool basically omnipresent, and passwords are saved in an hierarchy as regular files. Essentially it integrates well in the existent ecosystem and is easy to extend.
I think one would have a hard time getting a utility with the name "passhole" accepted into any large organization's toolset.
OK AdmiralAsshat >.<
The Admiral's wisdom comes from experience.
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.
1. presumably people using pass are using some sort of syncing system, which might be cloud based or otherwise compromised.
2. if that's "game over anyway", you might as well store your passwords in an unencrypted .txt file :^)
I probably could since I have my filesystem encrypted anyway and de facto do since my GPG keys are unlocked on login.
I know it's not FOSS but 1Password does have a decently fully-featured CLI client
Sadly, this CLI only pulls data directly from the cloud servers. So it can't be used when you have no internet connection or when 1Password is having server trouble.
I install my password manager's desktop/mobile apps so I can have an offline store of my password data. This provides a backup of the data in case their servers are down or otherwise inaccessible.
I wish the CLI has similar functionality.
Enpass has a CLI client and it's MIT-licensed.
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.
> 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.
You might already know about the Merge feature in general, but, curtosy of GHacks[1]:
> KeePass' synchronization algorithm merges matching entry levels when sync is invoked. The application uses the last modification date as the main data point when deciding about the recency of entries. KeePass keeps track of it automatically whenever an entry is added or modified.
> The application uses its history feature when it merges entries. Assume that the same login is available in two databases, but with different passwords. KeePass will merge these and set the most recent username and password as the default after the sync process completes. All other entries are stored in the history, so that they are not lost and may be accessed when the need arises.
I bet one could argue that this is at least as automated as a merge commit, which I wouldn't expect to run truly automatically anyways (ie. as a commit or ci hook without any other user input).
1: https://www.ghacks.net/2022/03/25/how-to-merge-two-keepass-d...
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.
They don’t have access to the ssh private key. They have access to the encrypted password file (and presumably not the password used to encrypt it).
The attack works when the user doesn’t realize they’re sending their SHH private key through the password form of malicious-site.com.
Something like accidentally putting your Google password into the Dropbox login form. Dropbox have now seen your Google password.
No, they clearly have access to the private key, otherwise they couldn’t copy it onto the path where the password is normally stored.
Also, they don’t need any password to encrypt the file, pass uses gpg encryption so they can just use the public key which will be sitting somewhere nearby.
You are misunderstanding the attack. The attacks requirement is: replace two encrypted files (e.g. by gaining access to someone's dropbox that contains the synced db), wait for them to leak "secretA" on "siteB" because `pass` doesn't securely bind secret and sites together. The attack is very realistic and high impact (but hard to perform).
Is pass able to decrypt ssh key files, or trick the user into decrypting them?
One of the files in the example is not a pass encrypted file but an ssh private key ("id_ed25519"). ssh private keys are either unencrypted or encrypted with a passphrase (but not via GPG in any case, and GPG of course is what pass uses).
The only way the outlined attack would be better than just uploading via curl is if pass could somehow enable the attacker to get a decrypted ssh private key. But I can't imagine why pass would be capable of doing that.
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.
The agent-driven nature of PGP, along with the encoding itself (which was primarily meant for emails) adds a lot of complexity, and makes it much harder to setup, configure, and use safely compared to other tools.
It is a tool trying to securely manage keys in an insecure environment, and even offloading some parts (such as to a yubikey) doesn't make it any easier to use.
> compared to other tools
Genuinely curious as to what other tools. I don't find PGP terribly too complex to setup or manage.
> It is a tool trying to securely manage keys in an insecure environment
I mean, yea. Isn't that every encryption tool on someone's local machine?
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.
feels like a stretch to call that a password store when it doesn't really have any password management functionality at all
OK. I'll rephrase that. Thanks!
Nice work. I know this is just a simple shell wrapper around gpg (which I appreciate), but if I was going to rely on this, I'd like to see:
Prefer just a simple MIT over GPL (and properly license your repo on Github)
Unit tests
Build it with CI/CD
Releases with tags
Available on a package manager (brew/apt/...)
What is the problem with GPL if you’re a user and not trying to reuse the code in a closed-source product for sale?
KISS
This is a simple script, it deserves a simple license.
Nobody is going to 'sell' just a simple one page script and nothing prevents me from looking at the arguments it uses and putting them into my own commercial product. You don't 'license' arguments to gpg.
It turns out that GPL is a much simpler license for very large enterprises. In fact, this GPL license was originally chosen because it's the simplest for one of my Fortune 50 company clients.
Simpler than what, MIT?
Yes simpler than MIT.
The Fortune 50's compliance team carefully evaluated many open source licenses, including MIT, BSD, GPL, Apache, etc. and determined that GPL is the best for their company for internal tools such as these, that must be wholly separate from any product offerings.
And when I say carefully, I mean multiple lawyers, for multiple years, considering many worldwide regulatory compliance laws. GPL won over all the other options.
Do you know what makes MIT and BSD more complicated for internal tools for these companies?
What about MIT or (two-clause) BSD makes it harder to comply with? Would attribution be an excessive burden for them in case such code ended up in their own products?
My understanding is that BSD and Apache were historically favorable licenses for code that was intended to promote a protocol and make it an industry standard. Easy reuse helped achieving this goal. For example, IIRC FreeBSD's TCP/IP code was repurposed for Windows and MacOS X, and the Apache HTTP server also went a long way toward establishing HTTP as a standard.
Edit: Paragraph on standards.
MIT and BSD et al. required the compliance team to track code, attribute it, audit it, and ensure that if the code ended up in the company's external products, then the company could prove the code was always correctly handled
This necessarily included all updates to the code, subsequent patches by external contributors that come downstream, subsequent patches by internal contributors that go upstream, eventual sunset of the code, etc.
GPL was akin to a bright highlighter stating "internal use only".
Creating a dependency on a 3rd party piece of software or releasing an internal tool as open source?
Dependency tracking was the primary issue because the company was in a regulated industry. Releasing patches for upstream existing open source was a secondary issue; GPL made this especially easy.
Good constructive feedback, much appreciated.
> Prefer just a simple MIT over GPL
Done. I added MIT or Apache-2.0 or GPL-2.0-or-later.
> properly license your repo on Github
Done. I added LICENSE.md file with SPDX links.
> Unit tests
Done. I added example tests. Do you have a preferred POSIX shell script unit test approach?
> And more...
Good ideas, all of them. I'll add your ideas to a new TODO section.
Thank you so much!
> 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.
GPG decrypts to standard output (by default), can take input from standard input so that Pass uses this to avoid plaintext on storage media. The issue that /dev/shm addresses has nothing to do with PGP. It is when you want to use a text editor to modify an existing multiline entry. Then the text editor needs a file to edit.
Fair points, I've checked source code and you are right, shm is indeed only used for editing, otherwise pipes are used.
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!
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...
Counter arguments:
- A password book can be lost if you bring it with you somewhere
- If you don’t bring it with you and you suddenly need to log in to something while you are not at home, you are out of luck
- There is no protection if the book is stolen. Now someone has all of your passwords.
- If your house burns down, do you have a backup of the book?
- Someone can shoulder surf you when you use the book in public and you might not even realise
- If your computer or phone is hacked they can wait until the next time you type the password for some service on the device and steal it then anyways
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.
>...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:
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.
I think KeePass is better than a bespoke format just because there are already clients written for it on every platform.
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.