[resoluteteeth]

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 pass is nice precisely because it's simple and basically just a wrapper around git + gnupg.

In comparison, most cloud password managers don't have these specific issues, but they are also very likely less secure in other ways.

[gruez]

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

[phoe-krk]

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

[Brian_K_White]

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

[gggggg5]

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?

[phoe-krk]

That's a strawman. I'm neither your Phillipino mother nor ever suggested that she should be doing this.

[Brian_K_White]

There is nothing invalid about the observation. (not a strawman)

[drpyser22]

The intended userbase of pass is clearly not non-tech-savvy/non-security aware philipinno mothers, so your remark is irrelevant.

[gruez]

>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 they can send a letter to github. I probably also expect github to do a better job at keeping their systems secure than an amateur sysadmin. In both cases the chance of getting hacked is fairly low, but the whole point of a password manager is that you don't have to rely on the storage service being secure to keep your passwords safe. If you need to rely on the storage service (eg. git server) to be not compromised for your passwords to be safe, then that kills a large benefit of using a password manager.

[yellowapple]

> If the FBI is after you, they can send a letter to your VPS provider just like they can send a letter to github.

And unless that VPS is in the US or provided by a US company, it's unlikely the FBI will get much of a useful response to that letter. Some countries' LEAs cooperate with the FBI and other American LEAs, but not all.

[phoe-krk]

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

[gruez]

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.

[phoe-krk]

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.

[gnoack]

Git over SSH to the Raspberry Pi.

You do not need a "hosted" git environment to keep a repo in a central location; a simple Unix account is enough.

[oats]

When I used `pass`, I synced the password store between all my personal devices with Syncthing (non-centralized file syncing tool) and kept the store history with git. This worked surprisingly well and was even pleasantly usable on my phone with a third-party android app I found.

[resoluteteeth]

I said github, not git. You don't need to use a cloud service to use git for synchronization.

[gruez]

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.

[eptcyka]

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?

[gruez]

> 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 that basically runs just sshd with password authentication disabled?

1. Same way that dropbox can be compromised: your account gets hacked or the provider gets hacked.

2. While I agree that a server with only sshd and auto-updates enabled would be pretty hard to compromise (foregoing the above), I doubt that's the typical setup. Most people probably have a "general purpose" VPS that they use to host all sorts of stuff, which means there's lots blindly typing in "npm install ..." or even "curl ... | sh" going on.

[resoluteteeth]

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

[msravi]

> 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

[msravi]

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.

[doubled112]

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.

[monopoliessuck]

> except for the site names not being encrypted

I just use ctmg authored by the same guy and a simple script to open and close both. If you want, you can then throw this anywhere.

https://git.zx2c4.com/ctmg/about/

[nixpulvis]

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.

[avgcorrection]

> but pass also isn't a cloud service [...] In comparison, most cloud ... cloud cloud cloud

The authors recommends KeepassXC instead.