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

171–180 of 186 posts

Re: Pass: Unix Password Manager

#171

Post by wkat4242 »

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…

For me the unstructured data is a big bonus. And it's not really unstructured. You can put Username: xxx and browser plugins like browserpass will pick that up.

Re: Pass: Unix Password Manager

#172

Post by wkat4242 »

maxmoehl wrote: post #89
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…

> It's very difficult to review history. I stopped using it a while ago, but since everything's encrypted `git diff` won't give you anything useful and IIRC the command line tools were very hard to use for reviewing/restoring passwords when you mess up updates, etc. pass sets up a .gitattributes and configures git to convert gpg files to text via a custom driver. This enables a text-diff of the encrypted contents out…

Eek doesn't this create a security hole? Or are those diffs gpg encrypted?

Re: Pass: Unix Password Manager

#173

Post by wkat4242 »

idoubtit wrote: post #148
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…

Other significant issues I've had with `pass`: - Important processes are undocumented. E.g. sharing the pass repository with another computer is not obvious: you need to copy more than the `.password-store/` directory... - Hard to install if not packaged. I tried to install `pass` on a headless NAS, but it required gpg, which looked hard to cross-compile to aarch64. - `pass` is a light interface over `gpg`. So it has…

If you move to age you will lose hardware backing though. No yubikey. That's the main attraction for me.

Re: Pass: Unix Password Manager

#174

Post by wkat4242 »

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…

I just leave my yubi plugged in. It requires a physical touch anyway (at least you can configure it for that which I have). And my place is physically secure.

The good thing also is that unlike with fido2 you only have to enter the pin once for OpenPGP. Then it stays unlocked while it's plugged in. But still needs the physical touch for every password. Perfect and convenient for me.

It also works great on mobile with openkeychain and password store. Both are not really maintained now but I don't really care because the encryption is in hardware anyway (yubikey over nfc)

Re: Pass: Unix Password Manager

#175

Post by wkat4242 »

nickjj wrote: post #147
jeduardo wrote: post #137

Earlier quoted context omitted.

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

I didn't like the idea of pushing a pass git repo to a private GitHub repo. For now I just temporarily drop the DB onto Google Drive manually (through the web site since I don't use the app) to quickly share it to the other devices without worrying about USB cables or running native apps on each device. Then I delete it from Google Drive. I'm hesitent to use "sync" type of tools that run on each device because I don'…

I would never upload it to GitHub either even though it's encrypted. It still leaks the metadata. And I don't believe in cloud anyway.

I just set up a simple git server in docker for it. Takes almost no resources.

Re: Pass: Unix Password Manager

#176

Post by wkat4242 »

echo42null wrote: post #74

Best practice question for syncing pass across devices: Since exporting and re-importing the private key to a phone seems risky, is the recommended approach to generate a separate GPG key pair on the mobile device and re-encrypt secrets to it?

I use yubikey over nfc with my phone. This way the private key material never reaches the phone.

Using the openkeychain app and password store.

I have multiple yubikeys as target for each password of course.

Re: Pass: Unix Password Manager

#177

Post by wkat4242 »

bborud wrote: post #124

If only chip makers and computer manufacturers could agree on some useful common interface for managing keys so we could get more people to use these solutions.

No please, I don't want my keys locked into Google or Apple. They can block your account on a whim with no recourse. At least bit warden can do it now but the fido association seems to have beef with them because it's possible to extract the private key. This is exactly what I want though, to store it somewhere safe.

But for now I simply don't use passkeys. It needs to be 100% open and cloud independent.

Re: Pass: Unix Password Manager

#178

Post by wkat4242 »

johannes1234321 wrote: post #83
Kwpolska wrote: post #75

Pass might work if you really like terminals and only use computers with a Unix-like OS. But if you use a phone, or Windows, pass is just too clunky to use.

The android "Password Store" app is okay'ish, integrates with accessibility API to offer auto fill in many apps.

It's perfect for me. And on windows and Linux I use QtPass and the browserpass plugin

Re: Pass: Unix Password Manager

#179

Post by wkat4242 »

jwgarber wrote: post #159
upofadown wrote: post #146

Earlier quoted context omitted.

From the linked page: > Notably, pass fails both of these requirements, ... , and the files themselves do not use authenticated encryption. With pass you can turn authentication on by setting an option to sign the files by default. That comes at the cost of requiring an extra entry of the passphrase so most do not turn this on. Few people are concerned with the idea that an attacker might modify their passwords so th…

This article goes into some of the deficiencies of using GPG with pass. In particular, GPG uses asymmetric keys, so someone could encrypt a new password file with your public key and you wouldn't know. https://rot256.dev/post/pass/

Well yes but this is also a feature: you can store passwords without having the private key available. That can be handy.

I don't really see the value in an attacker being able to store new passwords anyway. Besides, in order to do that they'd already have to have breached my private git server too.

Re: Pass: Unix Password Manager

#180

Post by conception »

diggan wrote: post #103
conception wrote: post #42

Earlier quoted context omitted.

It has dev environments now too! https://developer.1password.com/docs/environments/

Sounded nice, but I'm not sure what this actually adds. I'm currently using 1Password for doing "environments", but it's all using the existing `op` CLI. So adding a new collaborator to the project would involve adding them to the vault, then there is a shell script in the project that uses the CLI to write a new `.env` depending on the values from `op`. Seems like this new environment stuff wouldn't add anything com…

Yeah, I think the idea is instead of writing a .env you would, perhaps eventually, have a command like op that just loads the environment whole cloth. But you probably won't get much value out of that today.
Post reply on HN