Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

(In)Security of the “Pass” password manager

rot256.dev

Post reply on HN
Print view View original

81–87 of 87 posts

Re: (In)Security of the “Pass” password manager

#81

Post by jph »

latchkey wrote: post #74
jph wrote: post #63

Earlier quoted context omitted.

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 o…

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.

Re: (In)Security of the “Pass” password manager

#82

Post by nixpulvis »

torstenvl wrote: post #77
nixpulvis wrote: post #16

Earlier quoted context omitted.

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.

Re: (In)Security of the “Pass” password manager

#83

Post by NicolaiS »

eduction wrote: post #71
dwightgunning wrote: post #64

Earlier quoted context omitted.

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).

Re: (In)Security of the “Pass” password manager

#84

Post by thraxil »

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.

Re: (In)Security of the “Pass” password manager

#85

Post by selfhoster11 »

nixpulvis wrote: post #16
Evidlo wrote: post #6

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.

> 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.

Re: (In)Security of the “Pass” password manager

#86

Post by [deleted] »

NicolaiS wrote: post #83
eduction wrote: post #71

Earlier quoted context omitted.

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).

[deleted]

Re: (In)Security of the “Pass” password manager

#87

Post by eduction »

NicolaiS wrote: post #83
eduction wrote: post #71

Earlier quoted context omitted.

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.

Post reply on HN