

Pass: The Standard Unix Password Manager - jack7890
http://zx2c4.com/projects/password-store/

======
caladri
I'm not sure I see how this is in-keeping with any Unix philosophy I've
encountered. "Everything's a file" is good, yes, but this program is
needlessly-specific when what it does need not be. This is just a tool for
browsing a file hierarchy in which the files happen to be GPG encrypted,
right?

Which one thing is this doing and doing well? Merely being command-line and
somewhat file-oriented does not make Unix orientation. The utility has
numerous sub-commands, many of which are simply wrappers for other commands,
like find(1) or tree(1). An encrypted file-system or some other way of
encrypting the password hierarchy would seem to be exactly all the value this
adds over simply using the extant set of Unix command-line tools. Most of this
functionality simply duplicates the shell and cat(1).

It doesn't do one thing and well, it seems to do a small number of very
general tasks in needlessly-specialized ways requiring arcane and unfamiliar
incantations. The password generation stuff makes a fine stand-alone Unix
utility. But git integration in the same program?

This is a front-end which brings with it a considerable number of ideas about
policy, rather than simply providing a tool. Most of what it does could be
handled much more simply by the filesystem and the extant tools it leverages
or reimplements.

~~~
ralphtinner
Lotta facets of unix philosophy. It manages passwords and it does that well.
"pass -c HN/ralphtinner", and then my password is on the clipboard for 45
seconds. That's nice.

From TFA, the password generation is via pwgen.

Encrypted filesystems often require root privs or SUID helpers and don't have
straight-forward ways to do key management and key expiration. This tool
relies on gpg's already working agent.

~~~
repsilat
> From TFA, the password generation is via pwgen.

Seems strange to have the password generation "on the inside", though. That
essentially means that `pwgen` is a strict dependency. Instead of writing
something like

    
    
      pass generate Email/jasondonenfeld.com 15
    

the user should just type something like

    
    
      pwgen 15 1 | pass insert Email/jasondonenfeld.com
    

That way they don't need `pwgen` to install `pass`. It also means that all of
the options to `pwgen` can be used without special effort or documentation.

I'd say the same thing about `xclip`, but it's probably not worth having to
write something like

    
    
      pass -c Email/zx2c4.com | xclip -selection clipboard -l 1
    

(or however xclip is supposed to work).

~~~
zx2c4
Well, since pass is a shell script, and thus has no compilation, you don't
need pwgen, and then you can just use "some-generator-program | pass insert
blah" as you mentioned. For me, though pass generate Cheese 20 is a lot easier
to remember than having to think about the options to pwgen. Pwgen, by
default, makes passwords that are easy to remember, and there's some flag you
have to hit to make them "truely random". I can't ever remember what this flag
is.

With xclip, it's actually a bit more nuanced. You want this to be internal
because I have some logic for removing the password from the clipboard after
45 seconds and putting the old clipboard contents back (if nothing else has
replaced it in the meanwhile).

------
sciurus
This looks more elegant than the hacked-together system I'm using for my
passwords, but I don't see a way to store any metadata about the passwords
other than the name.

If you're looking for a command-line interface to a cross-platform password
database, there's kpcli for keepassx.

<http://kpcli.sourceforge.net/>

<http://www.keepassx.org/>

[http://search.cpan.org/~rhandom/File-
KeePass-0.03/lib/File/K...](http://search.cpan.org/~rhandom/File-
KeePass-0.03/lib/File/KeePass.pm)

~~~
nikcub
I also use my own homebrew system that stores the password encrypted in the
format of:

    
    
        ~/.passdb/username@site.com
    

I have a number of alises setup that will generate new passwords or retrieve a
password for a domain. for eg.

    
    
        $ p news.ycombinator.com
    

Will decrypt the password and store it in the clipboard. I don't see any added
benefit of having a complete application to manage this process, the ~20 lines
of shell script is just fine and I consider having to re-enter the master
password a feature.

Edit: I see now that this is just a shell script as well[1]. Nice. I might
take some ideas from it such as auto completion

[1] [http://git.zx2c4.com/password-store/tree/src/password-
store....](http://git.zx2c4.com/password-store/tree/src/password-store.sh)

~~~
zx2c4
Your system is basically the same. pass is not a "complete application", but
it's actually just a tiny shellscript. (RTFA...). You have to reenter the
master password if that's the way GPG is setup. Or you don't have to reenter
it, if it's set up that way instead.

Anyway, perhaps this is appealing to you: alias p="pass"

Check out the source of pass -- it's probably pretty similar to your bash
aliases. In fact, pass for me used to be a bash alias too.

~~~
nikcub
Scanned the article twice and it wasn't until I read the source that I saw
that it was a shell script.

That is the headline feature IMO (rather than 'standard')

edit: I should add that what gave me the impression of this being an
application rather than something I would really use was the way it was
presented with 'install', makefiles etc. rather than 'here are 30 lines of
bash you can dump into your rc file'

~~~
zx2c4
Cool! Hmm yea - maybe I should highlight that it's just a shell script
somewhere.

I already say " It is a very short and simple shell script. " in the first
paragraph. Maybe I should say something else too. Thinking...

Edit: responding to your edit: Yea, there's a lot of cruft that gets added to
a source directory when you try and make anything on Linux into something
suitable for /usr/bin and /usr/share/man. C'est la vie.

------
yason
Coincidentally, I've also been using a GPG based password manager called
'pass' for about ten years or so. I publish its source code here, straight
from my version control system called _.bashrc_ :

    
    
        alias pass='gpg -o - ~/Important/passwords.gpg'
    

The _gpg_ command will automagically use the relevant askpass dialog of the
desktop of my choice, which I've set to expire after fifteen minutes. The
above command will print a sorted list of entries in this format:

    
    
        site: username
        site: password
    

also known as a _text file_ and extracting specific passwords goes by
eyeballing the printed output or alternatively applying _grep_ to only extract
the stored data for a specific site. The final copying to the web browser
happens via manual operation of mouse selection and the clipboard. I get rid
of the plaintext passwords by actuating an operation called closing the
terminal window.

Works just fine! And I got to choose the format of the datastore myself, too!

~~~
zx2c4
Yes, this is how mine started, and it works alright, except you don't have the
niceties of clipboard management, password generation, really easy insertions,
or revision logging. Mine started out as basically identical to yours though.

~~~
yason
I could've guessed :) I've been resisting the urge to develop the text file
further for ten years—it's been a valuable lesson of what's good enough when
it comes to me.

------
acabal
I was just recently looking for a simple password manager for Ubuntu, and
Seahorse is _so close_. It unlocks with your login key so if you're logged in
you don't have to keep entering a master password each time you need to
retrieve a password; it stores everything in one easily-copyable encrypted
file; and it's a core part of GNOME. _But you can't store any metadata about
the password, like a username!_ And that makes it completely useless as a
serious password storage interface. What good is a password if you can't
easily store the username along with it?

If only someone would update Seahorse to store optional metadata along with
passwords...

~~~
zx2c4
Hopefully you're able to fashion pass into storing the data you want? I don't
like using my login key as a passphrase; seems flimsy, and I don't like having
to use PAM tie-ins and whatnot when I change the system password. GPG has gpg-
agent, so that it will keep the key decrypted for a set amount of time (or
until logout, if you prefer), so this has pretty much the same function.

Most importantly, a simple GPG file is not an obscure file format.

~~~
acabal
Pass seems excellent but for me is also almost-there, because it doesn't
unlock when I log in and I have to mess around with public/private keypairs. I
prefer using passphrases because I travel a lot and if I lose my private key,
it would be a monstrous hassle to get a backup private key in my hands
securely. `gpg -c` is my go-to.

For me, unlock on login is essential. If someone beats me unconscious and
steals my computer while I'm in a logged-in session, I have bigger things to
worry about than a potentially lost password database.

On a tangential note, we as a hacker community really have to work on de-
mystifying public/private keypair encryption. It gives me a headache to think
about it and I've been a programmer for over a decade. If it does that to me
then it's utterly unfathomable to laypeople and they're the ones who could
make the most use out of strong encryption, and who could become the champions
of privacy and security in the NSA-snooping age. But it's just too hard to
explain and use.

~~~
zx2c4
If you want to unlock on log-in, just have your gpg key unlocked by your login
password. Gnome keychain is capable of this. Your request is a definite
possibility.

I prefer having the key + passphrase over just a passphrase. It makes it more
difficult for the information to leak.

That said, if you'd like a pass with a gpg -c mode, it shouldn't be hard to
add. I could do this, or you could send a nice git formatted patch. Let me
know.

~~~
acabal
Anything is _possible_... but a program has to make it easy for us, i.e.
anticipate potentially popular use-cases and cater to them. Otherwise non-
techies will ignore the program and techies will roll our own simple solution
instead of taking the time to explore and customize someone else's--just like
I already have :)

(Although as a CLI program I suppose the argument could be made that non-
techies will ignore it on principle anyway...)

~~~
zx2c4
Sorry, I should have written more clearly: the functionality you want -- gpg
unlocked by login password -- is already available, implemented, and easy to
use. Look around on your distribution. It exists.

------
wmf
Calling unknown software _the standard_? Interesting approach. Fake it 'till
you make it I guess.

I wonder how this compares to factotum.

------
jrockway
I've written a number of filesystem-based databases, and the problem that
always comes up is keeping the entries consistent. You don't want a password
database where the master password is different between entries, but with this
system, you can't enforce that invariant until it's too late.

A better idea might be a system where the canonical source of truth is an
application-controlled database, but where you can export entries to a
directory tree and import entries from a directory tree. This makes syncing
more difficult (export to directory tree on both sides, rsync, import on both
sides), but it ensures that invariants are checked at sync time rather than
use time.

I suppose you can write a validation command that you always run after sync,
but how many people are going to run that? You don't realized you've been
burned by having an extra password for an obscure site until that happens.

~~~
Spooky23
That issue is solved here using GPG. Presuming you know how GPG works, your
golden. Groking GPG is an issue, however -- it's an app that is not exactly
user friendly.

For me, I love this, because I can secure passwords using my private key,
stored on a GPG card. Of course, there are probably less than 250 people on
earth doing that. :)

~~~
zx2c4
Whoa nice you have a GPG smart card? Very cool. There were some people giving
out USB tokens at FOSDEM which looked sort of neat but I haven't gotten it
working reliably.

GPG is mostly easy to use -- gpg -e -r someone@somewhere.com file.txt -- will
encrypt that file for that recipient. Most of the basic stuff are easy. For
creating a key and setting that up, I suppose this isn't super intuitive and
nobody has those commands memorized, but there are so many guides out there
for doing this. I think I started with the gentoo gpg guide
[<http://www.gentoo.org/doc/en/gnupg-user.xml>].

Anyway, you're correct -- this is one of the reasons pass uses GPG.

------
gyepi
I've been using (and updating) kedpm (python based FPM compatible password
manager with GTK and CLI interfaces. found on sourceforce and github) for a
few years now...

This looks like a nice addition to the growing menagerie of password managers.

All kedpm data, including entry names, are stored in an encrypted file. I
think unencrypted filenames is a kind of information leakage; I may not want
an attacker to know that I even a password to a specific service.

Also, I don't see a mechanism to search for entries. I have hundreds of
password entries so search (on any field) is critical for me.

With the ability to search (assuming it's fast), the first problem could be
mitigated by using generated file names.

~~~
zx2c4
Usernames aren't considered to be privileged data. If you're relying on your
usernames being secret, then you're making a big mistake and you should
rethink things. Alternatively, generic names.

For search, just use grep. "pass | grep whatever" has worked pretty well for
me when the tab completion did not. Or would you suggest an alternative
approach? I'm open to ideas.

~~~
gyepi
You're right usernames aren't considered privileged, but the list of services
and associated usernames is not the kind of information I would want to
necessarily make public. The names alone would be more revealing that _I_ care
to share.

Yeah, 'pass | grep foo' would work for search. I missed the default behaviour.

~~~
zx2c4
It's not as if you're putting the names on the internet. They're still on your
hard drive, beside your non-encrypted web browser session and history. For
this kind of protection, even though it's leaked in a million places
(unencrypted SMTP connections between mail servers when you receive the
'welcome to funworld' email, for example), there's disk encryption.

------
morpher
This looks nice. I've been doing something similar by hand for e.g offlineimap
and msmtp passwords that I didn't want to store in plain text. I had planned
on writing a similar utility to manage things, and it looks like now I won't
have to. Thanks for sharing.

~~~
zx2c4
Great! Glad you like it. Let me know if you have any suggestions or feature
requests.

------
Tyr42
Hey, It's now got a nice Homebrew OSX port. It's not accepted yet, so you'll
need to go

    
    
      brew install https://raw.github.com/zx2c4/homebrew/master/Library/Formula/pass.rb

------
dfcsd
It stores entries names in plaintext? Not very secure. I'll rather have
log.tmp file container (with all encrypted passwords inside) than
passwords\gmail.gpg

~~~
zx2c4
Usernames aren't considered to be privileged data. If you're relying on your
usernames being secret, then you're making a big mistake and you should
rethink things.

~~~
dfcsd
Single username isn't privileged data. But a set of usernames and realnames
can be. It's better to lose a pendrive with encrypted block256.dat than
Passwords\HackerNews\dfcsd.gpg, Passwords\Bank\34457356.gpg,
Passwords\Mail\name.gmail.gpg etc.

~~~
zx2c4
It shouldn't be considered secret, period. If you're worried about non-secret
data being used to attack you (the kind of data people can acquire by digging
through your trash when you bring it out to the curb, for example), then your
likely-to-be-lost USB key should be using some encryption of its own. This
encryption doesn't defeat the purpose of using pass, either, because pass uses
gpg agent, where the key nicely times out after a while, whereas disk
encryption is somewhat persistent. Regardless, username data isn't private,
even when you have multiple in once place; all that data can be put together
through other means.

~~~
gyepi
> the kind of data people can acquire by digging through your trash when you
> bring it out to the curb, for example

There's the difference, I think; I shred _all_ my personally identifiable
trash (well, recycling, actually).

~~~
zx2c4
Then you should also be using disk encryption, for your browser history and
whatever else.

