Live data from Hacker News

Pass: Unix Password Manager

passwordstore.org

161–170 of 186 posts

Re: Pass: Unix Password Manager

#161
post #153
post #87

Earlier quoted context omitted.

You can configure the yubikey to need a PIN and/or touch to authorise the use a GPG key. My main issue with pass is that it doesn’t work great on iOS with yubikeys.

Is the biometrics step (fingerprint reader) on macOS much different from a ubikey? I imagine implementation may have some differences, but in practice it seems I can already protect access to my GPG key using the built-in reader, so what’s the advantage of ubikey in that respect? Genuinely curious.

The TouchID is bound to a device - of course, I could copy my secret into a secure enclave that is only accessible through TouchID. Could even just store my GPG key there. With a Yubikey, I generate the key on an airgapped device and store it on the Yubikey. No other piece of hardware ever needs to see my secret key in plaintext. I could achieve the same with TouchID, generate the secret key inside the enclave, but then I cannot move the secret keys out without some other computer baring witness to that.

I really do not want to give Apple any more leverage over me, I'm looking to minimize it.

Re: Pass: Unix Password Manager

#162

Earlier quoted context omitted.

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…

> - 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... What do you mean? I copy my repo to new computers by just copying .password-store and I've never had a problem.

Isn't it just a git directory?

You should just `git clone that`.

Re: Pass: Unix Password Manager

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

I keep a Keepass vault with my 2FA secrets and a separate one with my passwords. This reduces the biggest fear I have where one compromise reveals everything.

These are both offline backups of my Bitwarden, which is my daily driver. Bitwarden doesn't store any of my 2FA info though.

Re: Pass: Unix Password Manager

#165
post #43

I have heavily used Pass over the years. Here are some of its pros (an update to my comment several years ago): * Your secret key can be stored in Yubikey, handled by a dedicated OpenPGP agent. This allows deriving a strong key from a weak one. Your password is basically a short PIN with max 3 tries. Every password retrieval can require a physical touch. This is convenient and secure! Pass makes sense if you use it w…

About mobile app, I never used pass until today, but it seems great, and so far I only tested it by installing it on my phone in Termux. Can't think of a reason for me to use a special app when running it in Termux works so well. Was happily surprised that even pass show -g worked out of the box, copying output to Android clipboard.

That is also nice since I have ssh already set up so syncing to my computer from the phone will be easy.

Re: Pass: Unix Password Manager

#166
post #147

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 didn't like the idea of pushing a pass git repo to a private GitHub repo.

I had the same reluctance at first, but after considering it was protected both with my gpg key and my passphrase, and private on top of that, I came to the conclusion it is fine for me. It feels assuring to have it in a remote location where it is safe if I have burglary or fire or an accident like that. My keys are in a few secure locations too

Re: Pass: Unix Password Manager

#167

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/

Yes, that is specifically what enabling signatures prevents. You would know when the stored password stopped working and the content of the rest of the file changed.

That article is fairly rough. For one thing it references "The PGP Problem":

* https://articles.59.ca/doku.php?id=pgpfan:tpp

For another thing it references "the quantum threat against cryptography" as an actual argument against password store.

Re: Pass: Unix Password Manager

#169

Earlier quoted context omitted.

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/

Yes, that is specifically what enabling signatures prevents. You would know when the stored password stopped working and the content of the rest of the file changed. That article is fairly rough. For one thing it references "The PGP Problem": * https://articles.59.ca/doku.php?id=pgpfan:tpp For another thing it references "the quantum threat against cryptography" as an actual argument against password store.

Yes signatures would prevent that, but as you noted it isn't enabled by default so most people don't use it. Optional security features don't count in my book :)

For the rebuttal you posted, I'll respond to one thing:

> The entire rant is basically about how OpenPGP is old and therefore bad and how new things, sometimes only vaguely defined, are good. So let's address this first.

> If someone, while trying to sell you some high security mechanical system, told you that the system had remained unbreached for the last 20 years you would take that as a compelling argument. You would be unlikely to demand a newer design. Normally old designs that have stood the test of time are valued. Cryptography is based on mathematical/logical principles. Such principles don't age out on any sort of a schedule and are valued in some cases for thousands of years.

The "unbreached for the last 20 years" conclusion about mechanical security systems does not immediately apply to mathematical ones, and we can indeed see that it is empirically incorrect. The cryptographic world is littered with the corpses of cryptographic algorithms that were secure for decades and are now broken (MD5, SHA1, DES, small RSA keys, TLS 1.0), and their C implementations that had horrible vulnerabilities (HeartBleed, etc). Mathematical proofs will not help us here either, since e.g. there is no proof that GPG is IND-CCA. (Which is unlike new systems, which do have proofs!) GPG had its day, and now it should be retired.

Also, the quantum threat is a reasonable one in the "store now, decrypt later" model. A lot of people presumably use git to store their password store online and would be vulnerable to this. The passwords in the files would probably not be important anymore once quantum computers are created, but any other long term data or other personal information that people store in there could be decrypted.

Re: Pass: Unix Password Manager

#170
I love this one. I use it every day.

What i love in particular is the combination with OpenPGP keys on a yubikey. Because of this you have two factor and more importantly, you unlock each password individually. This way an attacker can't steal your entire database of passwords even if they have full control over your computer. They can only see the passwords you unlocked. Because each password requires a physical touch on the yubikey.

With some other community favourites like keepass and bitwarden, once your database is unlocked, all the data is open..

Post reply on HN