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

51–60 of 87 posts

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

#51

Post by phoe-krk »

gruez wrote: post #44
phoe-krk wrote: post #41

Earlier quoted context omitted.

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

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.

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

#52

Post by upofadown »

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.

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

#53

Post by LanternLight83 »

gmuslera wrote: post #45

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

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

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

#54

Post by msravi »

gruez wrote: post #50
msravi wrote: post #47

Earlier quoted context omitted.

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

The vps can be encrypted by a customer supplied key. In google compute, for example: https://cloud.google.com/compute/docs/disks/customer-supplie...

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

#56

Post by eduction »

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.

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

#57

Post by upofadown »

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.

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

#58

Post by jph »

latchkey wrote: post #10
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.…

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

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!

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

#59

Post by jph »

zokier wrote: post #11
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

OK. I'll rephrase that. Thanks!

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

#60

Post by jph »

latchkey wrote: post #29
nequo wrote: post #26

Earlier quoted context omitted.

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