"brew install pass" -- the simple unix password manager now released for mac | Hacker News Reader

"brew install pass" -- the simple unix password manager now released for mac

zx2c4.com

61 pointszx2c480 comments

Seems useful, but aren't 1Password and Keepass better solutions?

1Password integrates with browsers, basically even avoiding the clipboard to autofill. It also prevents accidentally filling the wrong password as you can only autofill passwords that are for that domain. You can also sync to your iOS/Android devices.

Keepass is nearly as good (autofill isn't as refined), but it's free and available on linux too.

The point is to avoid the horrible bloat of 1pass and kees. I don't want a new database format. I just want simple files in simple folders, nothing fancy, nothing schmancy, easy to maintain, portable, standard.

1password is all JSON. Here's some python written by a friend of mine to read keychains:

https://github.com/drakedevel/pyagilekeychain/blob/master/ag...

Not that standard (the encryption is standard AES, but not OpenPGP format) but it is certainly portable.

Not that interested in kludging around with whatever interfaces and python helper scripts and exporters and importers and yada yada. I just want passwords in simple text files with no frills, and so should you. The Unix Way. This password stuff isn't that complicated, yet every other solution out there introduces such needless complexity. Slim things down, get back to the basics, and you'll have simpler but more efficient machines that can stack together in more robust ways.

Complexity in implementation maybe, but certainly not in usability. The browser integration is awesome. Click, enter master password (if authentication session inactive), click, done. A "simple" commandline tool makes the UX needlessly complicated. Open terminal, type 'pass name-of-file' (or if you don't remember it exactly, list all files, copy its name, paste), enter password EVERY TIME, copy username, paste, copy password, paste, close terminal. My computer has 8 GB of RAM for a reason. Let's use that to save me time and pain. The unix way is great and all, but it doesn't always make sense from the user's perspective.

With 1Password, you don't even have to click. You can just use the Command+\ shortcut in any browser, enter your 1Password password, press enter, and have 1P autofill and login.

Misses the point.

You're missing his point. pass looks cool and is the 'right' way to do it from a unix perspective. However for the vast majority of people out there, 1password and others are much more usable because they can access them from their phones without using a terminal and automatically fill in passwords with their browser.

It sounds like pass has the potential to do these things as well, and I would prefer to use an open platform over a closed one, all things being equal. Just recognize that there are tradeoffs.

I don't think there's any trade-off here. If you want a mobile app that isn't text based, a desktop app that isn't console based, or a browser auto-fill plugin, then it's fairly trivial to write one, considering the extremely simple design of pass. So stop whining, and write this component; it's easy. There is no trade-off. Full feature parity is a possibility.

I wasn't referring to the tradeoff between plain text formats and usability, I was talking about the tradeoff between 1password and pass as it is today. I realize the apps can be written, and I think it has the potential to be better than those other password managers.

So stop whining, and write this component; it's easy.

You would get a lot further in convincing people to use and contribute to your app if you toned down the condescension. I like your app and support unix tools with open formats but you come across as someone who would be very difficult to work with.

You're right to say that a < 250 line shell script doesn't match 1pass's bloat. But there are ways, and there will be ways to make all this happen, ways that are nice and clean and pretty, and don't add much additional complexity, as you've acknowledged.

Sorry you're put off by my dismissal. My inbox is filled with awesome patches and suggestions from people, and things have been going pretty smoothly with integrating these and fleshing out new features. You seem optimistic about the project (" I think it has the potential to be better than those other password managers"), and so if you've got the impetus to contribute some code or suggestions, by all means send me an email.

> or if you don't remember it exactly, list all files, copy its name, paste

bash tab completion...

I've been happily using 1Password for years now and have always been very happy with it. It syncs via Dropbox and I can access it anywhere I want. I have it on my Android phone via their Android reader. I don't see it as being horrible bloatware at all, in fact quite the opposite

I agree. Also, a common misconception is that your passwords are uploaded to a server with 1password. They are not! They are local on your machine, and you can optionally sync across your devices via your own dropbox account.

So do I, but I don't see where you enter the master password to access it before typing "pass". If I walk away from my desk for a minute or two, and someone points my browser at my bank, he'll have to enter a password. If he tries to ssh to my server, he'll have to enter the password. If he tries a sudo, he'll have to enter a password. I assume someone who typed "pass" at my command line wouldn't be given full access to my entire password store without having to enter, well, a password, right?

If I walk away from my desk for a minute or two, and someone points my browser at my bank [...]

To do that someone would already have to have typed your OS password to unlock your screen, right? If you're in the habit of leaving your system unlocked when you're not around it, you're already inviting someone to install a keylogger.

All the password management is handled by gpg-agent, which can be set to time-out your credentials after X seconds, on screen lock, when a bluetooth device moves out of proximity, or when it senses a disturbance in the force, as if millions of Macintosh users suddenly cried out in terror, and were suddenly silenced.

Gpg-agent is super awesome and flexible. Google it -- you'll dig it.

Yes, gpg-agent is super fancy, and if you and I weren't talking about the joys of "simplicity," I can see how it could be quite useful. (And thanks for pointing it out. If my needs get fancier, I might well decide to use it.)

But, for the moment, we ARE talking about simplicity. I'd like to simply encrypt a plaintext file. Then I'd have a decrypting version of cat (call it "dcat") that asks me for a password, doesn't echo it, and applies it to the file before cat'ing. It doesn't know if the password is right or wrong; it just passes the file through it before cat'ing. If I give it the wrong password, gibberish comes out.

I could then view a whole file (dcat my_secret_pancake_recipe.txt) or pipe it to grep (dcat my_logins.txt | grep -A 2 Netflix) to get just the lines I want---exactly what you'd do with any text file except that it starts with a decryption that asks for a password (which it doesn't echo).

What's the best way to do something this simple?

UPDATE: openssl essentially does this and comes already installed on Mac OS X. I'm a crypto noob, though, so I'd still welcome advice.

Yea, you could use openssl.

But GPG in general is the de facto unix way to go about crypting things. Straight up openssl is good for somethings, making little shell scripts like "dcat" is nice for others, but for general purpose encryption of files, nothing really beats GPG.

I guess GPG isn't simple. It's a big project, well-vetted, and has been under development for years. The usage of its tools, though, is very simple, and the file formats have now become an acceptable standard, widely adopted all over.

So really, give GPG another shot and a close look before you knock it. If it still doesn't meet what you're looking for, check out the man page for openssl-enc. Probably what you want is something like "openssl enc -aes-256-ofb -in infile -out outfile -salt", but likely there are other nuances to account for too. Be careful with crypto.

I used to use[1] vim with gpg and a plugin[2] to achieve something similar.

[1]: Switched to 1password a while back oddly enough, to achieve some simplicity.

[2]: http://www.vim.org/scripts/script.php?script_id=661

I'm not comfortable keeping all my passwords in a single companies database. They are good products, it's just a personal preference.

amen brotha

I have a question for those of you who use password managers like this: I have 3 computers, an iPhone, and an iPad, on all of which I interact with a lot of the same sites and applications for which I need passwords. How would I go about managing passwords for all the devices? Mobile devices in particular seem problematic.

More bloated password managers (like 1pass, for example) come with mobile clients and cloud services. This thread will probably include many such replies.

Pass comes with integrated git support, for syncing and logging. This is what I use with my mobile phone and additional computers, and it works really well.

Not being argumentative, I just don't understand.

How do you use it on your mobile phone? Is there a git app that lets you browse files? How would you decrypt them? Can you update them?

Or do you just use a shell on your mobile phone?

Yea so... I could make a nice fancy app, which I could do super quick because the design of pass is so simple. But instead I just use the terminal. Full clipboard support and everything with it. By the way, I'm using an N950.

Syncing via git (an active process) sounds like more work than passive DropBox syncing.

True. Autosyncers work with pass just as well. DropBox to your heart's content!

Google Drive or Dropbox.

Awesome idea. Since pass is just normal files, dropbox & friends can do things seamlessly. Didn't have that in mind originally, but it seems like it'd work really well.

I just put a KeePass file on my DropBox which automatically syncs to my devices.

I do the same. Portability of the password manager was as important as how it was stored. If I couldn't get it on my many machines, it wasn't any good to me. Highly recommended.

This is my method as well. I use iKeePass on my iDevice. It's not pretty, but it works.

Cool. You can put pass's password-store in Dropbox too!

Unfortunately, until there are mobile clients (using either Dropbox or git, I suppose), it's kind of a non-starter. I spend too much time on mobile devices now to not have that be a primary consideration. After using Keepass+Dropbox, I won't go to anything less convenient (and the problem-space doesn't intestate me to build a solution).

I use it on my mobile phone without a hitch.

I saw your other comment. Unfortunately, there is at least one, very large, platform where the terminal access is not really an option. Does Windows mobile OS provide terminal access?

> Does Windows

Thank you, come again!

Meh. Don't be platform-phobic.

Honestly, people use what is best for them. That may be Windows, it may be Linux. Point is, don't knock it if it works for them.

I'm not platform phobic. I've got more traumatic memories digging deep into win32 innards than I care to admit...

Point is, I'm not wasting my time trying to wrestle cygwin into shape, let alone investigating cygwin on windows phone.

That said, this could probably be re-implemented pretty easily using native win32 or .net... or whatever.

This does look pretty handy. I'd almost rather have my passwords stored in something like this, as opposed to LastPass where they are stored externally.

However, it would be great if this could work with Chrome as an extension. You'd probably want to avoid writing a native plugin for it, because that would require compiling and would be a headache for managing the extension (and gpg versions, etc). Instead, one thing you could do is setup a daemon that the extension could talk to, bound to localhost. But then you'd have to manage authenticating Chrome to the client, etc... perhaps I found something to tinker with over the weekend.

This would be totally awesome if you tinkered with this. I've been thinking about something similar too. It doesn't even have to be super complex, either. Shoot me an email (bottom of the page) and let's talk.

For what it's worth I'd take the #macintosh out of the URL as teh more important thing for me is seeing what this does / how it works. It's a neat utility but I had to do a double-take when the link opened installation instructions without an overview of what it actually does.

Yea, this would have been better. Will keep in mind for next time -- can't change it now.

Also (and I realize this is nit picky) you should change the section heading to "Mac" or "OS X".

"Macintosh" as a term to refer to a computer doesn't exist now. I can't find a link to support it, but I'm pretty certain Apple officially uses Mac, not Macintosh, even though the former was originally a shortened version of the latter.

p.s. Thanks for this software. Awesome to have choice in this area.

Omg, really? REALLY? Even though I'm not a "Mac" guy, this actually makes me kind of sad inside. I remember when my elementary school moved from a fleet of Apple II computers to the new amazing Macintosh. I always liked saying it too. Mac-in-tosh. A nice name for a computer. Alas alas alas.

I can't tell from the landing page: can this also save usernames/emails/security questions? Is there a "notes" field for each entry? I'd love to find a better alternative to KeePassX but I need to store these other pieces of info.

You can name the files whatever you want and put them in whatever kind of directory organization you want. You can also use multi-line mode to store additional information. (One thing I suppose I should add, then, is the ability for the clip mode to only put the, say, first line on the clipboard.)

Alternatively, and perhaps this is cleaner and nicer, you put the password in Amazon/bookreader and the meta/additional data in Amazon/bookreader.meta. Or come up with your own scheme that works for you. The system is really flexible.

Is it flexible enough to support separate fields? Having a multi-line "password" is kind of ugly... And if I want to save security questions, username, password and email, I'd need at least four files?

It is flexible enough to do anything at all. It is super duper flexible. There is no enforced scheme or organization. You can do things how you like.

One possibility I listed before was: Put your password in Amazon/bookreader and the other account information in Amazon/bookreader.meta. Then, this would be the case:

  $ pass Amazon/bookreader
  23nauDSJ92*#@nb23b2

  $ pass -c Amazon/bookreader
  Amazon/bookreader copied to clipboard for 45 seconds.

  $ pass Amazon/bookreader.meta
  Secret Question 1: Dog's name? Oliver
  Secret Question 2: Do you understand the concept here? I hope so.

The point is, you can organize things however you like. You don't have to use this scheme; you could use a different one.

I was looking for something like this (today) to keep some database passwords I need from time to time in git without storing them in plain-text.

Thanks for solving another man's problem.

My pleasure! Glad you dig.

This is the feature I would use this for. I've written custom solutions to do this in the past, and while I'm confident in them, it induces a large cognitive load to make sure they are secure. I would much rather trust another, well-vetted solution (meaning, of course, this has to reach well-vetted stage, but if I were in need, I'd spend time vetting).

GPG is well-vetted. The encryption here is GPG.

Odd-sounding request: Is it possible to have an option to not use gpg, or any encryption, at all? I only store my passwords on a LUKS loopback file, which I mount/umount as I need to access some information on it. The double-encryption does not really add any better security, but does add another password to type. I'd love to make use of the nice looking pass interface: A password generator, copy-to-clipboard, and simple management operations.

I'd still recommend using gpg so you get the nice time-out features of gpg-agent, but otherwise, if you still don't want to use it, sure, it's trivial.

Change calls to "gpg" to "cat" in the source code. It's less than 300 lines of simple shell script. Poke around and it shouldn't take more than 2 minutes to alter.

Here's another take on the problem: https://github.com/catch22/pw

Throwing everything in a single database file with a designated schema, YAML or whatever else, is exactly what I was trying to avoid.

Keep it simple. Single files are the way to go.

Wait, you password directory is stored unencrypted. Not the way to go.

The principal difference of opinion is that pass thinks usernames and sites are public information. Some of the alternatives do not.

While in some cases the difference is moot (I'm sure I have a bunch of registrations on things like forums where membership is public anyway), there are cases where it's not.

From the subtitle of the page: "the standard unix password manager".

I had thought that in 30+ years of Unix use, I had noticed all the standard Unix components. I was quite surprised to overlook that there was a standard Unix password manager!

Can someone explain a little more of how one would implement this for use on a phone as well as a computer? I have a Windows Phone personally, but an explanation for any platform would help conceptually.

If anyone has the motivation to port this to Windows-anything, I will laugh, cringe, and then give you a nice pat on the back.

That said, the design is pretty simple. There are gpg text files in folders. Decrypt them to reveal passwords, encrypt them to add passwords.

>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.

Is the filename cleartext or encrypted?

Filename is cleartext.

Thanks, I won't use it then.

What the hell? You can't encrypt filenames. I don't know where the hell you got the idea that you can.

Have you seen encFS?

Filenames readable in cleartext is a security issue. This means whoever has access to your files knows you have accounts on certain websites they are looking for.

You could store the password files in an encFS mount

By "encrypted filenames" what people are clearly talking about is making it so unauthorized people can not infer from the filename of a password file what website that password is for.

For instance, to store the password for www.example.com, the filename could be derived by encrypting the website name (www.example.com) with AES using the user's master password, base 64 encoding the output, and using that for the filename.

Usernames are not secrets. If you're taking tons of considerations for encrypting your usernames, your security model is just plain wrong, and you will be strongly disappointed when you survey the rest of the landscape (web browsers, email clients, web sites, keychains...). There's another HN post about this on a different thread. Alternatively, don't put sensitive data in the file name component.

If this could be integrated to work with Alfred that would be amazing.

I'm not really a Mac guy so I haven't played with Alfred, but from what I understand it's a launcher of sorts. Will it run executables that are in PATH with supplied arguments? If so, then you should be good to go. Or is there potential for tighter integration? What do you have in mind?

It can run shell commands directly by just prefixing them with > which then opens Terminal and runs the line. What I'd love is an extension (basically just a shell script) that would provide shortcuts to interact with it.

I really loathe 1Password, KeePass, LastPass etc. but what they do is provide me with a FAST way to get to my passwords.

If I could do this with Alfred and this app it would be killer:

pass find ycomb (and then it gives you results that match this and if you hit enter it copies the password to the clipboard) pass add [name/url] [password] pass rm [name/url]

etc. If only I knew how to code this. :)

Just poked at some random extension on the Alfred webpage. Looks like it's two plists and a png inside a zip archive that has a .alfredextension suffix. The plists have a pretty comprehensible XML format, and it should be easy enough to adapt one of these. Copy an existing one, edit the files and tinker around. Shouldn't take very long to do.

Shoot me an email (posted bottom of the page) if you have any success with this.

I haven't slept in a couple of days otherwise I'd take a crack at it myself, but Alfred extensions accept shell scripts. Just typing > in the Alfred bar gives you access to the shell, but I suppose you could use a script for more advanced automation (i.e. take this file/webpage/whatever and autofill).

Is there any way to make the completion on this work with zsh?

I found this thread searching for the same answer.

How would mobile phone usage work? Are there plans for an app? Or some easy way to use it when you don't have a full keyboard.

Should be pretty easy to write such an app, considering the design of pass is so simple.

Reply on news.ycombinator.com