Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pass: Unix Password Manager

passwordstore.org

Post reply on HN
Print view View original

131–140 of 186 posts

Re: Pass: Unix Password Manager

#131

Post by hamburglar »

debarshri wrote: post #130
hamburglar wrote: post #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 da…

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

Of course. This is absolutely never used for sharing. That’s why it’s called out as a drawback. When I need a shared credential, I’m forced to use a completely different mechanism. But this is pretty rare with good practices (which discourage shared credentials).

Re: Pass: Unix Password Manager

#132

Post by trinsic2 »

aborsy wrote: post #48
enkrs wrote: post #45

Browser password managers with passkeys are more convenient for me, but a pass vault can still be useful for recovery codes and API keys. I used pass for a while but couldn’t see what threat model it actually solves: If you let GPG agent cache your key, any script (e.g. an npm post-install) can just run `pass ls` or `pass my/secrets` and dump all your credentials. At that point it’s basically just full-disk encryptio…

That’s true for any password manager. If the database/store is unlocked (so the master password is cached or available in RAM), all passwords can be extracted. You have to lock the password manager when you don’t need it. In fact, with Bitwarden, the cached password is exposed to the browser that has a large attack surface (including interacting with random remote servers). There was just a vulnerability in most brow…

Doesn't good 2factor minimize a large attack surface like this?

I like the idea of storing password data in individual encrypted files and using git to store changes, but I wonder if it creates more friction to retrive the information. I havent tried this solution yet. I will when I get more time. It seems like this solution would benefit from a more standardized specification for storing and retrieving information. I known its not every persons cup of tea, but maybe some kind of separated add-on for streamlining this process could be beneficial.

Re: Pass: Unix Password Manager

#133

Post by jolmg »

denismi wrote: post #109

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

There's also `passmenu` that comes with `pass`. You setup a keybinding that calls that. It autocompletes your password selection with a menu (calls dmenu) and puts it on your clipboard. You skip having to invoke the command prompt then manually calling `pass -c` and writing the path.

Re: Pass: Unix Password Manager

#134

Post by liendolucas »

hamburglar wrote: post #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 da…

I've just discovered this two days ago from the SECUSO password generator: https://secuso.aifb.kit.edu/english/105.php

Initially I didn't get it, then I realized that it was using the deterministic password generation approach.

Offtopic: SECUSO has a really nice collection of open source apps.

Re: Pass: Unix Password Manager

#135

Post by jolmg »

lucb1e wrote: 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…

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

You can setup different directories to use different keys, and you don't need to limit yourself to a single key for each password either. You can use multiple. So you can setup structures like:

- admins/.gpg-id "admin\n"

- techs/.gpg-id "admin\ntech\n"

where admin and tech are 2 keys for different groups of people. Admin having more access. Or even better:

- site_foo/.gpg-id "bob\nalice\n"

- site_bar/.gpg-id "bob\nrobert\n"

where each employee has their own key. So you can fine-tune which passwords need changing if an employee leaves, and which passwords an individual employee needs to be able to access.

You can setup git submodules to control which passwords which employees can know to exist.

And given that git is being used, you can know which passwords an individual employee ever had access to, were their access to change over time.

Re: Pass: Unix Password Manager

#136

Post by avinassh »

rendaw wrote: post #58

There's a ton of positivity here, but on the balance there are some significant issues with pass that I think bear mention: - The fact that it's essentially unstructured data makes it hard to work with generically. If you have a username + password and need to use those in a script, you'll need to implement your own parser in your shell language in every script you need it in. - `pass generate` to generate new passwo…

> I've been working on something similar... although with slightly larger scope (intended to be used within containers/sandboxes) https://github.com/andrewbaxter/passworth

> stored in encrypted sqlite3

you had me at encrypted sqlite3. it would be great if you mention in readme that it uses SQLCipher

Re: Pass: Unix Password Manager

#137

Post by jeduardo »

nickjj wrote: post #118
denismi wrote: post #109

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…

That's curious. I moved from KeePassXC to pass precisely because the synchronization story for the database file wasn't working so well. For too many times I ended up with an outdated database in the backend server because the sync process failed to work properly.

After I moved to pass, every credential became its own file and I rarely edited the same credential in way too many devices. For the rare conflicts I had, having it being Git made it possible to resolve them without massive hassle.

Then again, that was also some many years ago. Maybe the synchronization story is better these days.

Re: Pass: Unix Password Manager

#138

Post by codethief »

johnisgood wrote: post #97
codethief wrote: post #80

Earlier quoted context omitted.

Memory isolation doesn't really help, though. If you have a malicious process running under the same user account as your password manager, it's still game over since that process could e.g. - capture keyboard input - capture your screen - silently install browser extensions to capture your credentials - modify your shell config, .desktop files, $PATH, … to have you e.g. call a backdoored version of your password man…

You can use Qubes OS for true VM-level isolation, or use hardware security keys where possible, or run sensitive applications in dedicated VMs. I think that in general it is game over the moment you have malicious processes running. I use firejail for most applications, which I believe is the bare minimum, or bubblewrap.

Yeah. Personally, I'm crossing my fingers for SpectrumOS[0] to make things a bit easier. As the developer notes on her website[1]:

   I have embarked on the ultimate yak shave
   it started with "I wish I could securely store passwords on my computer"
   And now I am at the "I have funding to build my own operating system" level
[0]: https://spectrum-os.org/

[1]: https://alyssa.is/about/

Re: Pass: Unix Password Manager

#139

Post by codethief »

codethief wrote: post #80
charcircuit wrote: post #69

Earlier quoted context omitted.

>That’s true for any password manager Modern operating systems isolate individual apps such that a malicous app can not access the RAM of another app. There is a difference between not making an effort to protect passwords and requiring an OS exploit to do so.

Memory isolation doesn't really help, though. If you have a malicious process running under the same user account as your password manager, it's still game over since that process could e.g. - capture keyboard input - capture your screen - silently install browser extensions to capture your credentials - modify your shell config, .desktop files, $PATH, … to have you e.g. call a backdoored version of your password man…

Ugghh, once again I forgot that HN removes line breaks unless you use double line breaks or indent by 2 spaces, and now it's too late to edit my comment.

@dang People keep running into this. (See e.g. this comment[0] from a few days ago.) It also makes it rather awkward to write lists IMO. What's the reason for removing line breaks and could this be changed?

[0]: https://news.ycombinator.com/item?id=44946386

Re: Pass: Unix Password Manager

#140

Post by kenmacd »

enkrs wrote: post #45

Browser password managers with passkeys are more convenient for me, but a pass vault can still be useful for recovery codes and API keys. I used pass for a while but couldn’t see what threat model it actually solves: If you let GPG agent cache your key, any script (e.g. an npm post-install) can just run `pass ls` or `pass my/secrets` and dump all your credentials. At that point it’s basically just full-disk encryptio…

If you can spare a USB port you can use one of their Nano keys that just stays plugged in.

Even if someone/malware was to steal my yubikey pin they'd still need to convince me to tap the thing over 1,000 times to steal all my passwords.

Post reply on HN