Hacker News new | past | comments | ask | show | jobs | submit login
Pass: The standard unix password manager (zx2c4.com)
159 points by po on March 30, 2014 | hide | past | favorite | 77 comments

There's one problem here: by storing passwords in a series of flat files, you give away that a password to a given site or location exists. That alone can be data that a user doesn't want to share.

I use a similar (and old) solution using GPG for password management, however it differs in one important way: it stores passwords in a database rather than a series of flat files. If I combine it with private browsing, I can simultaneously store passwords for particular websites while not letting a random trespasser know I even visit them.

An alternative would be to use KeePass, works very well on linux. It's one file, and that's it.


Thumbs up for KeePass.

I use it with the great PassIFox (https://addons.mozilla.org/en-US/firefox/addon/passifox/) to get a nice "Fill user/password" in the contextual menu.

I also use it on my Android phone with Keepass2Android: https://keepass2android.codeplex.com/

Same here, using the official one with Mono. It's a bit buggy, but still works properly most of the time. Do you use keepassx on Linux, and if so, does it work well?

KeePass is the program for linux I've found that fills in your details in the browser for you (short of LastPass, which I don't trust).

I don't use KeePassX. While it run/looks better on Linux (which is my main system), it doesn't support plugins (so no PassIFox, I could live without it but I'm lazy) and the interface is less mature.

Actually, thumbs down for KeePass from me - it's excellent on a multi user system. It totally sucks for a shared password store (like we tried to do in a company) though as you just can't effectively merge binary files in a Git repo. Pass could totally save the day here. I like!

You might find a site a colleague of mine runs useful: http://www.teampassword.com/

Just seconding the KeePass notion. It works very well on other platforms as well. This is my preferred option for storing my passwords.

keepass database+rw cli access: http://kpcli.sourceforge.net/

Thanks. This will come in especially handy if I mess up my X driver configuration again. :)

keypass is only available for Linux systems though an unofficial port. I would be hesitant to adopt security critical applications without developer approval.

KeepassX [1] is available (open source) for OSX, Windows, Linux, with great third party apps for Android, iOS. With the db file in Dropbox it works like a charm across all platforms!

[1] http://www.keepassx.org/downloads

It's not unofficial - KeePass 2 runs as a Mono app natively. There's a few rough edges, but the developer accepts patches fairly readily.

The developer doesn't have a public facing repository and instead just dumps the source code for each new version - making it really difficult to see what has actually changed.

You can see the commit activity for KeePassX, which would make it more obvious if a bug or malicious snippet might get inserted into it.

It's even in the official Debian/Ubuntu repositories for ages, so I'm not that much worried.

I have a (WIP!) fork which fixes this exact problem here at:


Take a look. I am using it personally, Its not in a release-able state yet, though. I have had no time to work on it.

Ssh used to store "known hosts" in the plain, but they changed it for exactly that reason. Noe it stores the hash of the host your connecting to.

Right, if pass had a way to have a mini-database within a file that would be great. You could still organise into multiple database files.

I guess you could do something with pass's multiline option.

What database do you use?

Funny you should mention this. I have a post-in-progress I'm writing about my experiences moving from KeePassX to Pass. I sync my password information online, so Pass has obvious problems. I ended up mounting the Pass directory as an EncFS volume, which still gives up information about how many entries there are, but not what they are. http://www.arg0.net/encfs

by storing passwords in a series of flat files, you give away that a password to a given site or location exists

Those file names are arbitrary. While it's certainly easier to just name them after the site or resource you access with the password within, you can give them some cryptic identifiers.

How would you remember that <cryptic identifier> corresponds to <your email site>?

  $ pass insert mapping -m

I've considered a password management system many times but I can't think of something that's not over-engineered.

So, for the last 20 years or so, I just have a single GPG encrypted file that contains the list of my passwords for various sites and services, ssh keys, and whatnot. I usually read and write that file in Emacs, or gpg -o - out to shell with an alias for quick read-only access.

The file is easy to backup and easy to distribute even carelessly: I even had it on my public www server at some point when I needed access to the passwords over the network.

I can't think of a simpler scheme than that.

Of course, the GPG keys themselves can lock and unlock my life completely. I have them in a separate backup file that is also encrypted using GPG but with a symmetric cipher. Thus, I don't depend on any extra files to decrypt my GPG keys.

As the passphrase for that symmetrically encrypted file is basically the master password to my life and because I've never needed it yet I store the password in a suitable physical location. But I can still distribute the backup file itself: even obtaining the passphrase to the symmetric cipher doesn't really expose my secrets yet. It will only give access to my GPG keys which in turn need my regularly-used private-key-passphrase to be useful at all.

I used to do the exact same thing as you, actually -- all the way down to keeping your keys with a symmetric pass & storing that in a secure physical location (for me, a safe deposit box). I switched to pass about a year ago because:

-it's the same scheme, the only difference is that your passwords are broken into individual encrypted text files instead of just one (potential SPOF advantage).

-it's more secure because you can set it up so your passwords never reach stdout (or any human readable display at all for that matter) with pass -c.

-it's just as easy to backup:

  gpg-zip --symmetric ~/.password-store
-pass itself is extremely portable.

-pass is way more convenient:

  pass -c my/password
is far quicker and several orders of magnitude less annoying than

  gpg -dao passwordfile.gpg

  <unlock private key>

  <copy password>

  <kill terminal>

  <use password>

  <clear clipboard>
Speaking from experience, I would say you're better off using pass than a single gpg'd text file.

> -pass is way more convenient: > > pass -c my/password > > is far quicker and several orders of magnitude less annoying than > > gpg -dao passwordfile.gpg > <unlock private key> > <copy password> > <kill terminal> > <use password> > <clear clipboard>

I agree with your sentiment, but if you keep your passwordfile well-formed, say:

    site.com username password
    #assume no spaces in password or username -- or use tabs
You could throw something like:

    gpg -dao passwordfile.gpg|awk "/${1}/ { print \$3 }" | xclip &&
     sleep 15 ; echo XXXXXXXXXXXXXXXXXXXXXXXXXX | xclip
In a script. With an agent managing your gpg passphrase (or not, depending on your pranoia) such a scheme would get most of the way there.

Not sure why you would want to kill the terminal, but you could just <command-run> or whatever said script...

In fact, for clearing your clipboard, just selecting some text should be enough -- but I supppose it might be considered a feature to have it in the script, in case one forgets.

Thanks for the comprehensive comparison. Pass does have advantages, I think I'll evaluate it myself too. The main selling point is the clipboard support.

My solution is similar--I have a tiny script of bash and gawk called "greppass" that I use to pull passwords from a colon-delimited text file. I don't encrypt mine (ssh, don't tell anybody) because the whole volume is encrypted, which I consider to be good enough.

I think even yours is over engineered.

I just write them down at home with a mental rule for replacing char position.

I do something similar, albeit more in fashion with the gp: I have a small-ish truecrypt container that has a "passwd" directory in which each service gets its own txt-file. The same container also holds a handful of other essentials, like a backup of my gpg keys and revocation certificates, ssh keys, emacs config, zshrc/bashrc and so on.

In each of the txt-files, I use a shorthand for the passwords. So if the actual password was "theansweris42", I'd have something like t...s42. This is enough of a reminder for myself (especially when using a more modular password system), without giving the full password away. In another, external gpg-encrypted file, I have a simple txt-file that contains both the password for that truecrypt container and the "translation" for the long form, i.e. t...s = theansweris and so on. This allows me to also use this file as a kind of dead-man switch. Should I ever die unexpectedly and somebody close would need or should have access to my accounts, they will be able to open the GPG file (because they are in it as recipients), which essentially gives them access to everything important.

I use a similar method, but with ccrypt: http://jonblack.org/posts/using-ccrypt-as-a-password-manager...

I recently switched from 1Password to pass (on a mac). At first I missed how easy it was to hit "cmd+\" to fill in a web login form, but I made a little shortcut that has similar functionality.

First, I created an automator action that grabs the current URL from Chrome and strips out the hostname. This gets passed to a new Terminal window that runs a shell script that calls "pass -c" for the hostname.[0] Then the script calls terminal-notifier [1] and a notification pops up that reminds me of the username and any other info for that site (but not the password). [2]

Then I bind that service to the "cmd+\" keyboard shortcut and I have something that ends up being more reliable than 1password's often flaky form filling functionality. It includes the extra work of entering username manually and pasting in a password, but so far I like this system a lot better. Also, for sites that use the same login from multiple hostnames, I just create symlinks to a "canonical" pass entry.

Hope this is useful to some people on a mac!

[0] I couldn't figure out how to have pass ask for a gpg pinentry window when it was getting run from a non-interactive shell. So I use automator to create a new terminal window, then destroy it at the end.

[1] https://github.com/alloy/terminal-notifier

[2] all of my pass entries are of the form:

   username: user
   other info: foo
   other info 2: bar

This is useful - thanks for this. I think I'm going to give something like this a try. 1Password has been getting incredibly flakey over the past few years, and I'm just tired of dealing with it (especially in Safari).

The reason I stuck with it so long was so that my passwords would easily sync to my iPad/iPhone, but with iCloud Keychain, I think I'm finally ready to give up on 1Password.

I don't know about 1Password, but IIRC the iCloud keychain is laughable security, with easily brute forceable pin-based security that can be performed at Apple HQ without your knowledge.

You remember incorrectly, to some extent.


Probably, but it's pretty damn convenient. To be fair, I still use 1Password for "critical" passwords (e.g., my personal email address, my credit cards, my bank accounts, etc). But yeah, security is a concern...

I think there are official 1Password browser extensions which allow for the shortcut cmd-# to fill forms automatically.

I came across Pass when I was looking for a password manager a while ago. I don't use it, but it is responsible for the idea behind my super simple workflow.

I have a folder, ~/pass. It contains gpg encrypted text files. They are named by category. So, a product key would be keys.ftl.gpg. A website would be sites.hackernews.gpg.

I create and edit files with emacs. It handles gpg files and lets you choose which key to use to encrypt.

For random password generation, I use pwgen.

That's it. Being files, you can ls and grep to see if you already have an account somewhere or find out the file name that belongs to a site. If you are concerned with "giving away" where you have accounts if the system is compromised, you can create larger generic files like "sites" and then use your text editor to search through them.

It's simple, easy to backup via rsync and cross platform because gpg, emacs and pwgen are on every platform. When the SSD in my Linux machine failed I was stuck using Windows for a month while the RMA went through. It was trivial to get up and running with cygwin.

Can your describe your exact process? How do you plug pwgen into emacs?

I know emacs an do things like that, but I never bothered enough to find out if it's as smooth to use as keepass2.

There would be ways to plug it into emacs, but I don't bother since it's only 1 of 2 or more destinations for the password. Browser usually being the second.

pwgen has a bunch of options. They are fairly easy to learn, but you can always alias them out to something descriptive. Usually I have to specify some arbitrary length based on the "recommendation" of the site in question. Eg:

  pwgen 10
Will poop out a bunch of passwords to the console in columns that are 10 characters long. Probably less then ideal. I usually like to use the secure option and make them as long as the site will allow. To make things easier, you can just make it generate a single password and pipe it to the clipboard.

  pwgen -s 20 1 | xclip -i

Middle click (paste) into emacs and the web browser. Save the file in emacs and submit the browser registration form. Run the pwgen/xclip command again to put a different unused password in your clipboard just in case.

Honest question: despite work-related stuff (like, for a sysadmin or whatever), in a personal scenario how many passwords do you guys have to manage so it's worth using an app for that? I only have 5 active (and other 2 old) entirely different passwords for types of usage and each have between 13-18 chars with capitals, numbers and all the shit. I just store them in my mind. What's the real/basic use case for passwords managers?

It's recommended that you have a different password for every site, not just for every type of site. If, for example, someone discovered your forum password, under your system attackers could take over all of your forum accounts.

Lots of us sign up for lots of sites to try out things, engage in one-off discussions, etc, so it's pretty necessary to have a password manager.

I'll point out that if you creates those passwords yourself, rather than using an entirely random generator, they likely have less entropy than you think, and so are more crackable. A password manager helps with that.

> I'll point out that if you creates those passwords yourself, rather than using an entirely random generator, they likely have less entropy than you think, and so are more crackable.

So true. I generate my passwords separately, for the simple reason that I haven't yet found a pssword manager that would fit me perfectly. Pass is getting relatively close.

In the meanwhile, I keep my passwords either on [LUKS] encrypted partition or a GPG protected file. I can even disclose the exact method I use for generating these passwords:

  head -c 9 /dev/urandom | base64 -
For high-value targets or if I'm feeling a bit more paranoid than usual, I go for 12 octects instead.

You could get higher entropy with

apg -a1 -n1 -m9 -x9

since it will have a greater alphabet

Entropy in bostik's example is controlled by the -c parameter to head, not by the size of the destination alphabet. If you increase the number of bytes read you'll see the length of the resultant string start to grow accordingly.

I use a different 32 chars alphanumeric password for every site I'm registered at (http://a.pomf.se/zpubyy.png), so it's easy to have 20+ passwords to remember (I have ~35 in my keepass database), which is a bit hard to do without a password manager.

I guess the use case is if you're a bit paranoid and want to use a strong/different password for everything.

Password reuse is really bad for security. And without password reuse it is easy to see how the number of passwords explode even in moderate use.

I use different randomly generated passwords and randomly generated answers to those stupid security questions for every identity I have, which is a lot. I was willing to trade money and time to use a third party tool to manage these, because I can't remember an arbitrary number of arbitrarily long strings of nonsense.

Apparently, i have 887 entries in the osx keychain. Mind you, some sites show up multiple times.

I try to use a different password for each new account. Since the password manager handles the credentials for me it's not much more effort than reusing the same login/password everywhere.

I have 25 passwords managed by pass, all personal and not work related.

This is awesome, I might even switch from LastPass to this. But I can't brew install it because the pinentry dependency is broken. Great idea though.

It's a small bash-script, if you have the time add an option to use something else then pinentry ?

What's wrong with pinentry? It seems to work OK on my mac.

I use an GPG-encrypted .org file. With Emacs' built-in support to open GPG files, it's simple and convenient.

I do the same with vim, but I suspect this is better for isolation of the database, since you're not unlocking the whole thing every time.

also if it starts using hashed versions of hostnames to store files, I don't see why a single file is better.

Regardless of what editor you use, be careful that it isn't leaving copies of your passwords other places on your filesystem. For example vim will save your recent yank registers in ~/.viminfo by default. You can avoid this with vim -i NONE or you can chmod your .viminfo to 000.

An alternative that doesn't leak information on site, very barebones, but you can just drop-it to your .bash_profile or similar https://gist.github.com/pyr/9870029

This looks like a very neat tool, but the difficulty with many of these systems is the need to install the password software and have access to a copy of the password data file(s) If you login to many different systems, possibly on different OS platforms, then they all need to be kept in sync every time you change or add a new password.

Here I've listed a few other password management options with pros and cons: http://ss64.com/docs/security.html

And what exactly is standard about this?

Is it really worth it to do this rather than just using the keychain that comes with your OS/DE which fully integrates with your browser's auto fill functionality without extension?

Can you easily back that up and take it across platforms?

I like this stuff. I'm crazy about terminal utilities and this one is a must, but when it comes to passwords, I have them stored in my head, with a pattern. I can go to a website after 5 years and still remember what I'm supposed to type, so I guess I'll stay with this option.

  Known issues:
  - If you're drunk, it's a bit difficult to remember anything 
  - If you're sick, probably won't work properly as well
  - If you're dead, won't work, 100% sure

I've been using this for about a month now and it's great. It's just encrypted text files but that's all it really needs to be.

I've been using this for the last couple of months with syncing through Dropbox and it works just fine!

For quicker password access, one should try passmenu[0]. It's a dmenu-based menu with all the entries and selecting one copies password to your clipboard.

[0] https://github.com/cdown/passmenu

I've been using pass for over a year and am really happy with it, particularly the part which keeps passwords in sync over multiple machines.

No mishaps so far. My default behavior with new sites now is to just let pass generate a secure pw and give up any hope of remembering it.

And yeah, I'd definitely use a mobile version.

Create a new document in vim, save with the :X command and enter an encryption key. If you open the file afterwards it will ask for the key. I've been using this for years, works like a charm.

Beware: the default encryption method is very weak and can be brute-forced by anyone who knows a few characters of the original file. Since v7.3, Vim supports Blowfish, which is much stronger.


> Since v7.3, Vim supports Blowfish, which is much stronger.

No. Even the designer of Blowfish thinks you should not use it anymore: https://www.schneier.com/news-048.html

That doesn't contradict what I wrote, though. As far as I know, Blowfish hasn't been broken, and while it's theoretically less secure than its successors, it's still a valid choice if you want to use Vim's built-in encryption, which only supports pkzip and blowfish.

Great utility, though is less useful than browser extension that makes it easier to store/restore credentials. Also, lack of mobile support would prevent me from switching to it from Lastpass.

This looks cool. There's one piece missing that would make it ideal for me: I want to replicate the encrypted files onto my android tablet and access them from an app there.

Yeah, if there were an Android app I'd try this out in a heartbeat. I use Lastpass currently but I haven't been liking the direction it's recently taken. This seems like a much more elegant solution, but it's a no-go if I can't use it on my phone.

I use ccrypt to encrypt a file containing my passwords. To find a password you can do: ccat password-file | grep <some-keyword>. Simple and to the point.

Any plan on making this follow the "Secret Service" (system keyring) freedesktop standard? Then it will be accessible to programs via libsecret.

What's this GPG stuff? Do I just make a key and then I can open any of these files when I'm logged in? How do I go about doing that?

The script delegates to the GPG binaries where necessary. From the 'Using...' section:

"There will be a nice password input dialog using the standard gpg-agent (which can be configured to stay authenticated for several minutes), since all passwords are encrypted."

When setting up the pass store, you also specify the identity of a GPG key to use (or set of keys which may be used).

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact