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

71–80 of 87 posts

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

#71

Post by eduction »

dwightgunning wrote: post #64
eduction wrote: post #56

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

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.

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

#72

Post by aborsy »

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.

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

#73

Post by est31 »

upofadown wrote: post #52
est31 wrote: post #20

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.

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

#74

Post by latchkey »

jph wrote: post #63
latchkey wrote: post #62

Earlier quoted context omitted.

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

Creating a dependency on a 3rd party piece of software or releasing an internal tool as open source?

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

#75

Post by jkepler »

resoluteteeth wrote: post #46
gruez wrote: post #39

Earlier quoted context omitted.

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

> 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

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

#76

Post by drpyser22 »

Brian_K_White wrote: post #70
phoe-krk wrote: post #67

Earlier quoted context omitted.

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.

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

#77

Post by torstenvl »

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.

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?

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

#78

Post by gggggg5 »

Brian_K_White wrote: post #66
phoe-krk wrote: post #27

Earlier quoted context omitted.

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?

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

#79

Post by upofadown »

aborsy wrote: post #72

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

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

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

#80

Post by jph »

nequo wrote: post #69
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…

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

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

Post reply on HN