Live data from Hacker News

Pass: Unix Password Manager

passwordstore.org

121–130 of 186 posts

Re: Pass: Unix Password Manager

#121
post #23

This is fun if you never leave yourself, but be wary with whom you share it. As a company password manager, there is no way to know who's accessed which secret across their lifetime at the firm so you get to change all the passwords constantly. (Or none, if you can't be bothered.) (Don't ask.) Or if someone newly needs access, there's no standard way of re-encrypting the files you're guessing they need. You need to h…

My and my buddy have been using “pa” for our company with great success: https://git.j3s.sh/pa

It uses age and allows you to use multiple keys for encryption

Re: Pass: Unix Password Manager

#122
post #96
post #21

This is interesting for CLI lovers, but I feel KeepassXC on desktop + KeepassDX on Android (with the password DB stored on my own machine and accessed remotely via Wireguard) is a better solution for normies.

keepass has a very underrated feature i never see much talk about where you can have multiple vaults and have them open and search both at the same time (or at least the two apps you mentioned support that anyway). most password managers are based around the idea of one single vault which creates the problem of having to treat every password like it needs the maximum amount of security. in my own case i would guess m…

Also, KeepassXC and OG KeePass with a plugin can auto-open another vault from an entry in the primary vault. This works well if you have the more secure vault open a less secure vault, or in my case open a shared vault used for common passwords off a network share at work.

I also preach the tiered password security model. For the common, frequently used passwords that don't need max security, I just use the browser store (with a copy in KP).

Re: Pass: Unix Password Manager

#123
On MacOS, I tried using the Password App for passwords, but there is no cli to access it in scripts.

The keychain is accessible with a cli, but is not very nice to work with. Which is a bit sad, because being able to use touchid when running a script or signing commits would be nice.

Re: Pass: Unix Password Manager

#125
post #68

Earlier quoted context omitted.

How do you have 1300 passwords? Sounds like a lot. Come to think of it though, I have no idea how many I have.

I checked, also just over a thousand. So it seems normal, in the same order.

Interesting. I have 165 total. Could be because I use Google oAuth whenever it's available.

Re: Pass: Unix Password Manager

#126

How would you build a dead man’s switch for pass? I’d like my family to be able to access my store if I disappear, but not before. The obvious problem: to re-encrypt for their keys I’d need my private GPG key running somewhere, which defeats the point. Has anyone solved this cleanly without leaving a hot key around?

The beauty of pass is that there's a distinction between giving access to the encrypted vault vs giving access to decryption, and you can leverage this. How I've been doing this is that I have 2 (sets of) backup people. The first set has access to the repo, but can't decrypt. The second set can decrypt (i.e. I have their pubkeys imported), but don't have access to the repo. I've chosen the people such that it's unlik…

Thanks, I totally forgot about both sides; I only looked on the side of the key.

Re: Pass: Unix Password Manager

#127
post #39

Happy pass user for ~8 years now, have ~1300 passwords stored. No issues whatsoever. Use git to sync it across devices, totally awesome.

How do you have 1300 passwords? Sounds like a lot. Come to think of it though, I have no idea how many I have.

I have ~1300 items in my 1password vault too. Seems normal

Re: Pass: Unix Password Manager

#128
post #118

I recently moved away from pass after a decade or so. Two main reasons: 1. This laptop up was set up with flatpak versions of all GUI applications, including Firefox, and the browser plugin just doesn't work. I persisted with the work-around of `pass -c ` from the run command prompt for a while to paste into the browser, but its not ideal. 2. I realised that the Android app was archived. There's at least one fork, bu…

I made the switch from pass recently too. I had ~400 secrets stored in it for almost the same time as you. Ultimately I wanted something easier to sync between multiple devices. Now that I am traveling more seriously I can't get away with only having a few important passwords saved on my phone and laptop. It was a lot easier to sync (1) file with KeePassXC and it has 2 well supported Android apps to choose from. It t…

KeepassXC combined with Syncthing is enough for me too.

Re: Pass: Unix Password Manager

#129
I have a different approach I’ve used for about 10 years that I like a lot. All password metadata is stored in a plain JSON file indexed by name (usually site name). Each entry contains at the minimum a username. Optionally it has a version number and some password rules like the length (20 if absent) and the character classes that are allowed, along with how many of each character class are required. None of this data is sensitive, so if you look at the file you see my list of sites. The actual passwords are not stored, because my tool is actually a deterministic password generator, which prompts me for a passphrase and generates a password from the passphrase and a hash of all the metadata. One nice feature is that if I just change the version number I get a whole new password, and the “history” is still available by changing the version back.

The one major downside to it is that it is absolutely unusable for sharing passwords because obviously that would require sharing my passphrase, and there is no way to “store” a password that someone else set. I’ve thought about writing a mode that would encrypt a string (eg a shared password) with the metadata-generated password and store it in a separate piece of metadata for that purpose, but the number of times I’ve needed that has been extremely small.

Re: Pass: Unix Password Manager

#130

I have a different approach I’ve used for about 10 years that I like a lot. All password metadata is stored in a plain JSON file indexed by name (usually site name). Each entry contains at the minimum a username. Optionally it has a version number and some password rules like the length (20 if absent) and the character classes that are allowed, along with how many of each character class are required. None of this da…

Sharing passphrase becomes even bigger risk as now your surface area is larger as comprise will lead to many credentials bei g leaked.
Post reply on HN