61–70 of 186 posts
If you are using age instead of GPG for encryption purposes, I've found this to be useful: https://github.com/FiloSottile/passage
Pass is great, but GPG keys are complicated and add a lot of extra overhead if you don't have one already. Frankly I cannot recommend anyone use GPG today for any purpose. I wrote a much simpler CLI password manager instead that meets explicit security models. https://codeberg.org/jwgarber/napa/src/branch/main/database....
Why would you want to store arbitrary individual passwords instead of deriving them with on demand from the service name/domain and a common secret?
Not all sites are safe, either by design or by people running them. Having a common secret+service name as password AND having at least one of those sites leaking your plaintext password could mean that your derivation may go public and all your other passwords and services fall because of that.
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.
Earlier quoted context omitted.
No need to forego mobile if you're on iOS [1]. 1. https://apps.apple.com/us/app/pass-password-store/id12058205...
This app wasn't working for me last time I tried it. Granted that was a few years ago.
This app is keeping me on iOS as there is no single-app replacement on Android afaik.
Related: https://github.com/gopasspw/gopass
I haven't used pass in a long time, but I used gopass for a while in a small team and it was pretty great.
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…
Fair, but you can use your own conventions.
> - `pass generate` to generate new passwords, maybe thanks to the above, replaces everything in the pass value by default. So if you had e.g. a password + secret question answers, if you use `generate` to get a new password it'll wipe out your secret question answers.
Just split it into `site/pass`, `site/secret-question`, etc. The fact that it's just using a directory tree is quite nice.
> 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
`git diff` would be an odd command to run on generated passwords even without encryption. What matters is that you know when the last change was for a password or site with `git log `, and you can just `git checkout -d ` if needed.
> - The name makes it nearly impossible to search for
in the terminal `$ pass` typically suggests the associated package.
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.
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…
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.
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…