Live data from Hacker News

(In)Security of the “Pass” password manager

rot256.dev

41–50 of 87 posts

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

#41
post #37

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

The VPS does not have my private GPG key, stored locally, and hence cannot use it to decrypt the passwords.

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

#42
post #28

Earlier quoted context omitted.

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.

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.

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

#43
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

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

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

#44
post #37

Earlier quoted context omitted.

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

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.

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

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

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

#46
post #39
post #31

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

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

#47
post #39
post #31

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

> 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

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

#48
post #28

Earlier quoted context omitted.

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.

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.

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

#49

I know it's not FOSS but 1Password does have a decently fully-featured CLI client https://developer.1password.com/docs/cli/

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.

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

#50
post #47
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…

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

Post reply on HN