Hacker News Reader

Comment by sasvari | Hacker News Reader

pass - the standard unix password manager

  Password management should be simple and follow Unix philosophy. With pass,
  each password lives inside of a gpg encrypted file whose filename is the
  title of the website or resource that requires the password. These encrypted
  files may be organized into meaningful folder hierarchies, copied from
  computer to computer, and, in general, manipulated using standard command
  line file management utilities.

http://www.passwordstore.org/

View on HN

Downside of pass is that the filenames are in the open. Thus, metadata (which sites you have account on) is not secured. Linked one seems to store everything in a single encrypted file.

Upside is that it has ton of implementations readily available - browser integration, mobile apps, etc. Linked one (passbox) is just a bash script at the moment, if one wants to use it across multiple devices and platforms, the experience may be quite rough.

Another upside is that with a single file model you have to invent your own conflict resolution scheme. For pass, git just does the trick. And this one doesn't seem to have anything in this regard.

...filenames are in the open.

Is this something that can't be fixed by directory perms?

If you trust the box.

That said, if you have a secure trusted machine with FDE that you don't let strangers touch, and where every piece of software is well-isolated (for example, web browser is sandboxed and can't access the ~/.password-store/), then yeah, filesystem permissions will do the trick.

But, for example, if you sync using git repo hosted on some third-party VPS then directory permissions won't protect you from that host owner or whoever gains superuser access to the filesystem.

(Hey, don't downvote the parent, he didn't said anything wrong, just asked a question! In my opinion that contributes to the discussion.)

I agree. Perhaps a zip file with a password?

> Downside of pass is that the filenames are in the open.

The "entry" names (which I think would correspond to filenames in `pass`) appear to be passed on the command line here; they'll likely get swept up in your shell's history file, unless you're careful. (And thus, are essentially in the open, just like pass.) That said, I think most shells make their histfiles 600, so they're not directly readable. (And I think `pass`'s directory is 700, similarly.) And you have to trust the machine you're running on, of course; otherwise, I can just dump the memory as soon as your keyring is decrypted.

I think it was when `pass` was on HN that I mentioned this; I have a terminal keyring manager myself[1], but one of the design decisions I made in it (aside from a single-file archive) was to not pass entry names on the command line, specifically so they won't get swept up in histfiles. It's easy, though, it make it optional, and let the user decide what they want to do. Of course, your

[1] which is way not ready to be looked at… also seems like we as a crowd enjoy this topic (keyrings) as a side project.

There is HISTIGNORE for a reason ;)

But, yeah, if one forgot to add pass there, the metadata will be leaked.

I did not know about HISTIGNORE! Very interesting. I knew about HISTCONTROL=ignorespace, though I did not know it was a variable; I just thought that was a hard-coded feature.

the standard unix password manager

Annoying amount of hubris.

This pile of unattractive bash-snippets is neither unix nor standard. Just call it what it is: A very dependent script that will probably work on most GNU/Linux distributions.

Good shout, I've added it to the 'Similar Projects' section of the readme.

I had a play with 'pass' before but i wasn't keen on the way it splits the entries up into separate files which was one of the drivers for putting passbox together.

Is there a way to share passwords with passbox? pass lets you encrypt different files with different keys so it could potentially be used within an organization with varying levels of permission. Another advantage is that each password is just an encrypted file that could be read with just GPG if pass isn't installed.

Not really, i wanted this to just be a personal password manager and sharing passwords is mostly out of scope in that respect. Although there's nothing stopping you having multiple 'passbox.gpg' files of different names with different keys by manipulating the PASSBOX_LOCATION env variable within aliases or something like that.

You can still decrypt the file with just GPG if you wanted and modify the file in plain text. Passbox just acts as a layer on top of that to interrogate the encrypted GPG file.

I've been using pass since mitro.co announced their shutdown.

The only (somewhat big) downside to this, and related unix pw managers is the sheer lack of browser compatibility - mobile would also be nice, as that's one of the places where it's a PITA to use and enter long passphrases.

pass claims to have both, but doesn't:

https://github.com/jvenant/passff#readme does not work.

The iOS app has disappeared from github: https://github.com/rephorm/pass-ios#readme

It's solvable problems, I just find it a somewhat important part of a password manager.

I suppose it just depends what you look for in a password manager. I tried lots of solutions from Last Pass, KeepassX to pass but i prefer the scriptability and portability of a command line based password manager and i'm not overly bothered about mobile and browser.

You're right, and don't take this as a challenge, I'm honestly wondering:

How come you aren't bothered? I ask because I can't image apart from:

a. I use short or cryptically unsafe passphrases,

b. I use passphrases and type them easily,

c. I only need to log in a few times.

Am I forgetting others?

For non-mobile use-cases the passmenu script distributed with pass comes in handy:

http://git.zx2c4.com/password-store/tree/contrib/dmenu/passm...

It types the selected password via xdotool.

I'm running a small agency with two friends and we're keeping mitro alive (and better: are fixing issues) here: https://passopolis.com/

Firefox and Chrome extensions are working, and I'm currently spending a few hours a week on migrating to the new Firefox-extension protocol.

Reply on news.ycombinator.com