Pass: The standard Unix password manager • Hacker News Board

Re: Pass: The standard Unix password manager

#171

Post by teekert » Wed, Apr 14, 2021, 9:17 AM UTC

spuz wrote: post #170

mjgs wrote: post #167

I discovered a couple of years ago that iTerm2 has a password manager, as well as other cool features like live text highlighting via regex. Anyway it was the first time I had ever used a password manager that you can call directly in the shell. It’s awesome, and once you memorise a few simple key combos it’s super easy to input stored passwords in the shell.

Why would you want a password manager in your shell? How many times do you need to access password authenticated services from your shell?

Do you use the same pw for all your encrypted SSH keys? Btw, [0] works well for 2fa on ssh keys.

[0] https://www.akamai.com/us/en/products/security/akamai-mfa.js...

Re: Pass: The standard Unix password manager

#172

Post by moviuro » Wed, Apr 14, 2021, 9:19 AM UTC

mattacular wrote: post #35

PureParadigm wrote: post #4

I've been using pass for several years now and I recommend it to my friends, but I usually get weird looks when I say I store my passwords in a git repo (it's not as bad as it sounds!). Here's why: - I host my git repo on my desktop computer (through SSH), so it's not exposed anywhere except if you have SSH access to my computer. (A lot of people seem to think git = GitHub which is not true). So if your git repo is n…

It's worth mentioning though that your repo could leak metadata about what accounts you have, and your username, depending on how you name your pass entries (ie. you can mitigate it by adopting a more cryptic naming scheme for sensitive entries). Just something to be aware of, it may not matter for your use case. Bitbucket still offers free private repos, which I use for my password store.

Check out https://github.com/roddhjav/pass-tomb

Re: Pass: The standard Unix password manager

#173

Post by tazeg95 » Wed, Apr 14, 2021, 9:24 AM UTC

spicybright wrote: post #11

PureParadigm wrote: post #4

I've been using pass for several years now and I recommend it to my friends, but I usually get weird looks when I say I store my passwords in a git repo (it's not as bad as it sounds!). Here's why: - I host my git repo on my desktop computer (through SSH), so it's not exposed anywhere except if you have SSH access to my computer. (A lot of people seem to think git = GitHub which is not true). So if your git repo is n…

How do you get your passwords out of the repo on your phone?

https://fr.jeffprod.com/blog/2019/gerez-vos-mots-de-passe-av... (french)

Re: Pass: The standard Unix password manager

#174

Post by chriswarbo » Wed, Apr 14, 2021, 9:28 AM UTC

bobbylarrybobby wrote: post #130

aborsy wrote: post #37

Here are some of the pros of the Pass: * It leaks meta-data. That might sound a con, but in exchange you get the ability to extract a password without decrypting and thus exposing other passwords. There is isolation. * It’s more convenient than a single file password manager. You type ‘’pass -c goo’’ for your Google account, instead of clicking on your password manager, typing password, searching in data base, findin…

Can you use it on mobile?

I use it for 2FA (via https://github.com/tadfisher/pass-otp ) on my OpenMoko (QtMoko). I installed it via apt-get from the normal Debian repos.

Re: Pass: The standard Unix password manager

#175

Post by tasuki » Wed, Apr 14, 2021, 9:29 AM UTC

rhardih wrote: post #159

For any LastPass users out there contemplating a switch to pass, I just recently did so myself. Wrote a bit about it here: https://rhardih.io/2021/03/migrating-from-lastpass-to-pass/

I'm a LastPass user contemplating a switch. Your article doesn't say why I should switch. You mention "more control", and that's my thinking as well, but it just appears... not worth it to switch for something so nebulous? Perhaps I'm too lazy?

Re: Pass: The standard Unix password manager

#176

Post by jayjader » Wed, Apr 14, 2021, 9:32 AM UTC

dopidopHN wrote: post #138

taeric wrote: post #43

Earlier quoted context omitted.

The asymmetric point is surprisingly useful.

And convenient. The only minor road block I sometimes encounter is when a website has dumb rules for password. I have to generate a auto one. Then edit it manually to make it comply to « no @ in password » or whatever dumb stuff like that

Just fyi, `pass generate` has a --no-symbols option that should save you some time in the future.

Re: Pass: The standard Unix password manager

#177

Post by zikduruqe » Wed, Apr 14, 2021, 10:01 AM UTC

I’ve been using Pass for years, and love it.

Question for HN... is there a project that anyone knows of, that is using Age instead of GPG as the encryption for Pass? I’ve seen a few implementations of it, but nothing I’d use for a daily driver yet.

Example, not my project - https://github.com/somasis/passage

Re: Pass: The standard Unix password manager

#178

Post by KMag » Wed, Apr 14, 2021, 10:04 AM UTC

aborsy wrote: post #37

Here are some of the pros of the Pass: * It leaks meta-data. That might sound a con, but in exchange you get the ability to extract a password without decrypting and thus exposing other passwords. There is isolation. * It’s more convenient than a single file password manager. You type ‘’pass -c goo’’ for your Google account, instead of clicking on your password manager, typing password, searching in data base, findin…

> There might be few cons though. For example, if you store your database on a cloud, say, Dropbox, Dropbox could switch your Dropbox.com file with google.com file, and you copy and hand over your Google password to Dropbox. But this is hypothetical for most of us!

Before I became aware of Pass, I wrote essentially the same thing, but in Python.

Fast-forward a decade or two, and my wife uses a password manager that got deleted from the Apple AppStore, and iPhone backups just contain pointers to the app to install upon backup, not the actual binaries. So my wife had her password database, but no password app. I did a bunch of research on password database formats, and this is recognized as a pretty common vulnerability.

Pass allows you to add arbitrary metadata, so I suggest adding the domain (or better yet, the login URL) as the second line in the encrypted file. I made this automatic/mandatory in my home-spun Pass-alike.

Re: Pass: The standard Unix password manager

#179

Post by KMag » Wed, Apr 14, 2021, 10:07 AM UTC

smegcicle wrote: post #59

aborsy wrote: post #37

Here are some of the pros of the Pass: * It leaks meta-data. That might sound a con, but in exchange you get the ability to extract a password without decrypting and thus exposing other passwords. There is isolation. * It’s more convenient than a single file password manager. You type ‘’pass -c goo’’ for your Google account, instead of clicking on your password manager, typing password, searching in data base, findin…

> For example, if you store your database on a cloud, say, Dropbox, Dropbox could switch your Dropbox.com file with google.com file That's sad- could we include a hash to detect stuff like this?

Make the login URL (or at least the domain) the second line of the encrypted file. Pass supports arbitrary metadata.

Re: Pass: The standard Unix password manager

#180

Post by KMag » Wed, Apr 14, 2021, 10:11 AM UTC

PureParadigm wrote: post #128

smegcicle wrote: post #59

Earlier quoted context omitted.

> For example, if you store your database on a cloud, say, Dropbox, Dropbox could switch your Dropbox.com file with google.com file That's sad- could we include a hash to detect stuff like this?

What you probably want is a signature. Since pass can be a git repo, you could use git to sign your commits [1]. But you'll have to remember to check the git commit signatures or automate checking it somehow. [1] https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work

Restricting to a git repo and making sure to check that the commit is signed and there's no diff to current would work, but it's easier to just put the login URL (or at least the domain) as the second line of the encrypted file (Pass allows arbitrary metadata).

OpenPGP (GPG / etc.) use a MAC on the file, so an attacker can't modify the encrypted file and still get it to decrypt (at least without some flag to ignore broken MAC). An attacker could create a new password file for you for their domain, but then they'd have to make up a random password for you that's not going to match your FriendFace/Congo/Vigintillion password.