7 ms·

Pass: The Standard Unix Password Manager

40 points by jack7890 14y ago

jrockway 14y ago
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.
- zx2c4 14y ago
  This seems really complicated. The whole point is to keep things simple and easy and not bloated with lots of applications and database formats and whatnot. In any case, the GPG files have the ID of the key needed to decrypt them, so you can encrypt files with different keys, and so long as you have that key in your keychain still, you're good. I guess I could add a simple convenience command "pass normalize" that decrypts everything and re-encrypts it using a single key. This would be a pretty simple way of doing it.
- Spooky23 14y ago
  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 14y ago
    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 http://www.gentoo.org/doc/en/gnupg-user.xml]. Anyway, you're correct -- this is one of the reasons pass uses GPG.
  - jrockway 14y ago
    I have a GPG smartcard. The problem is that no readily-available card readers work under Linux. I had one on a Dell laptop of Core Duo vintage many years ago; after I got a new machine, I could never find a working card reader.
jewpiterjones 14y ago
w00t a simple password manager that isn't totally bloated that I can use from the commandline. gpg is awesome too
caladri 14y ago
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 14y ago
  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.
  - zx2c4 14y ago
    Exactly.
  - repsilat 14y ago
    > 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).
sciurus 14y ago
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://kpcli.sourceforge.net/ http://www.keepassx.org/ http://www.keepassx.org/ http://search.cpan.org/~rhandom/File-KeePass-0.03/lib/File/KeePass.pm http://search.cpan.org/~rhandom/File-KeePass-0.03/lib/File/K...
- zx2c4 14y ago
  This was exactly what I was trying to avoid. I don't want this big behemoth. I want something small and easy and simple. A file for each password. If I want additional data, I can just use multiline. Or, I can establish a .meta convention if I please. Or this, or that, or whatever. It's simple, and can be used in a million different mashups.
  - joshka 14y ago
    mbox vs maildir...
- nikcub 14y ago
  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.sh http://git.zx2c4.com/password-store/tree/src/password-store....
  - zx2c4 14y ago
    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.
acabal 14y ago
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 14y ago
  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 14y ago
    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.
    - 14y ago
morpher 14y ago
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 14y ago
  Great! Glad you like it. Let me know if you have any suggestions or feature requests.
dfcsd 14y ago
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 14y ago
  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 14y ago
    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 14y ago
      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 14y ago
        > 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).
        14y ago
gyepi 14y ago
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 14y ago
  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 14y ago
    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 14y ago
      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.
wmf 14y ago
Calling unknown software the standard? Interesting approach. Fake it 'till you make it I guess. I wonder how this compares to factotum.
yason 14y ago
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 14y ago
  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 14y ago
    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.
Tyr42 14y ago
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

40 points by jack7890 14y ago

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.

zx2c4 14y ago
This seems really complicated. The whole point is to keep things simple and easy and not bloated with lots of applications and database formats and whatnot. In any case, the GPG files have the ID of the key needed to decrypt them, so you can encrypt files with different keys, and so long as you have that key in your keychain still, you're good. I guess I could add a simple convenience command "pass normalize" that decrypts everything and re-encrypts it using a single key. This would be a pretty simple way of doing it.
Spooky23 14y ago
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 14y ago
  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 http://www.gentoo.org/doc/en/gnupg-user.xml]. Anyway, you're correct -- this is one of the reasons pass uses GPG.
- jrockway 14y ago
  I have a GPG smartcard. The problem is that no readily-available card readers work under Linux. I had one on a Dell laptop of Core Duo vintage many years ago; after I got a new machine, I could never find a working card reader.

jewpiterjones 14y ago

w00t a simple password manager that isn't totally bloated that I can use from the commandline. gpg is awesome too

caladri 14y ago

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 14y ago
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.
- zx2c4 14y ago
  Exactly.
- repsilat 14y ago
  > 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).

sciurus 14y ago

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://kpcli.sourceforge.net/ http://www.keepassx.org/ http://www.keepassx.org/ http://search.cpan.org/~rhandom/File-KeePass-0.03/lib/File/KeePass.pm http://search.cpan.org/~rhandom/File-KeePass-0.03/lib/File/K...

zx2c4 14y ago
This was exactly what I was trying to avoid. I don't want this big behemoth. I want something small and easy and simple. A file for each password. If I want additional data, I can just use multiline. Or, I can establish a .meta convention if I please. Or this, or that, or whatever. It's simple, and can be used in a million different mashups.
- joshka 14y ago
  mbox vs maildir...
nikcub 14y ago
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.sh http://git.zx2c4.com/password-store/tree/src/password-store....
- zx2c4 14y ago
  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.

acabal 14y ago

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 14y ago
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 14y ago
  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.
  - 14y ago

morpher 14y ago

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 14y ago
Great! Glad you like it. Let me know if you have any suggestions or feature requests.

dfcsd 14y ago

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 14y ago
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 14y ago
  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 14y ago
    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 14y ago
      > 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).
      - 14y ago

gyepi 14y ago

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 14y ago
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 14y ago
  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 14y ago
    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.

wmf 14y ago

Calling unknown software the standard? Interesting approach. Fake it 'till you make it I guess. I wonder how this compares to factotum.

yason 14y ago

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 14y ago
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 14y ago
  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.

Tyr42 14y ago

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