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

11–20 of 87 posts

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

#11

Post by zokier »

jph wrote: post #4

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

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

#12

Post by nixpulvis »

resoluteteeth wrote: post #7

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…

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.

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

#13

Post by codetrotter »

appleaday1 wrote: post #5

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

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

#15

Post by AdmiralAsshat »

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

I think one would have a hard time getting a utility with the name "passhole" accepted into any large organization's toolset.

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

#16

Post by nixpulvis »

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.

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

#17

Post by gruez »

blfr wrote: post #14

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 :^)

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

#18

Post by nixpulvis »

AdmiralAsshat wrote: post #15
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

I think one would have a hard time getting a utility with the name "passhole" accepted into any large organization's toolset.

OK AdmiralAsshat >.<

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

#19

Post by gruez »

resoluteteeth wrote: post #7

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…

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

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

#20

Post by est31 »

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.
Post reply on HN