* Separate file for each secret, so that I can store the password on the first line and then other sensitive account details on subsequent lines.
* -c flag for copying passwords to clipboard (but only copies the first line of the file, so it doesn't interfere with the usecase above)
* tab completion for user account names. However, this comes at a slight cost to security -- anyone with access to your machine (or git repo) can see all of the websites / accounts for which you have a password.
* Everything happens via the file system and secrets are just gpg encrypted text files. So it's really easy to implement new utilities on top of your password store. This is true for this solution as well, but somehow having separate files for each account makes it safer to implement utilities that do account management.
This nice solution is minimal, well scripted and very UNIXy. However, one tradeoff is that filenames for the stored password are plain. Running the tree command on the directory where encrypted files are stored would give us something like,
For this reason I'm thinking of switching from gpg to encfs. It has an option for auto-unmounting after a period of unactivity. It would also play well with programs that need to read password from a file.
Has anyone else here had the same thought? This guy seems to at least;
That would mean two stages of password query, which I think might be a con. Also, the file names would either not be encrypted in the git repo or not be compatible with e.g. Android app I guess.
Thanks for the autofs hint, will try it and see how that works out re unlocking.
You can avoid a lot of these types of issues using a digest for the username and password plus a master key as a salt. It generates a unique and relatively complex sequence for each site and doesn't require any persistent state other than the salt.
The downside is a lack of control over complexity and the issue of passwords being strictly dependent on the salt. So, if one set of credentials is compromised, you would need update them all.
I've seen software that does this, but there are subtle details to consider to actually get it correct.
It's a definite tradeoff, I agree. But I think pass is on the correct side of this tradeoff:
1. ./blah.sh | grep LookupKey exposes just as much information as pass -c LookupKey. If someone has access to your machine and you don't carefully prune your bash history file, then you're screwed. However, in the latter case, at least you get something at the cost of giving up security -- namely, the convenience of tab completion.
2. The only way to solve problem #1 in general is to have multi-stage authentication, where you authenticate to access to lookup keys and then authenticate again to access the passwords. That's achievable using pass and some Bash -- obfuscate file names and store a obfuscated -> actual mapping in a gpg-encrypted file, and write a bash script that does the ln -s'ing. And then the command that does that dumps you into a shell that doesn't record history.
I did this for a while but found it's a bit of PITA. Also, I can almost always come up with names that would be difficult to exploit without a lot of information about my life (bank_primary, bank_secondary; email/personal, email/business, email/spammy; server/personal, server/2011; and so on. I won't remember these verbatim, but once tab-completion reminds me of my options I typically recall which is which. And in case you're afraid in several years you'll forget which server you first purchased in 2011, you can always just pass -e server/2011 and explain which one you meant in subsequent lines.
Another reason for me is the cross-platform compatibility.
With git, I'm able to synchronize passwords across OSX and Linux machines,
and the features (even copying) work well on both platforms.
"This is pre-alpha quality software, the result of a three
day project. It will crash your browser, leak your
passwords and destroy your home. This is actually my first
Chrome extension and I am no expert javascript programmer."
For Safari (and Chrome) I made a little automator service that gets the url from the browser, strips the hostname, then feeds that into a shell script that calls pass and puts the password in the clipboard for 45 seconds.
It actually works better (for me) than 1password which was always a little flaky at recognizing a website after any kind of site update.
passwordstore just (with my distro) starting shipping a dmenu (http://tools.suckless.org/dmenu/) script that I think is great, and personally removes the need for a browser extension. Unfortunately only available on linux.
It would be nice if there were a way to integrate it with the OS X keychain, unfortunately I haven't gotten around to it and I haven't been able to find anyone who has done this already since it's tricky to google.
Yep, I use it to provide passwords to my shell scripts, for example. security<->pass integration is precisely what I'm looking for, I get the feeling I'm going to end up having to implement it myself.
It would be nice if I could at least export from the OS X keychain (you can always write up a simple script to add them to pass). Internet accounts can be exported, but all the rest won't work.
I've given up on it, but I'd like to know if anyone might have found something that I overlooked.
Have you tried the security commandline utility? As far as I know it reads anything you want from the keychain. For example, to grab what password Spotify is storing in my keychain: `security find-generic-password -s Spotify -w`
It's some time ago that I tried exporting, so I don't recall exactly what I did. As far as I know, I tried it with that command line tool but it simply wouldn't export everything.
There's also the issue that if it does export something, you have to accept every exported item individually. If you search the internet, you'll find people who wrote scripts for "automatic accept-clicking."
But as I said, once I looked up what it exported, I noticed that it was far from complete.But maybe there's some command line option buried somewhere that will accomplish what I wanted to do...
This works because Emacs can open .gpg files. It will decrypt them on opening (asking for your password) and encrypt on saving. This is very powerful in combination with Orgmode (.org), or any other module that provides auto-folding.
So I open my .org.gpg file and everything is folded. Then I search for what I need, and only that part (containing some secrets) is unfolded.
Of course, this is no substitute for a proper password manager, but proved to be useful a lot more often than I initially thought.
I'm not sure this is a good solution for this use case (password management).
The obvious way of getting the password out of the Emacs buffer is copy and paste, which leaves the password on the clipboard where it is very easy to find. Manually removing it (by copying something else) can't be relied upon. (If you use Klipper you have an even bigger problem.)
I know all bets are off with any kind of password manager if the host is compromised, but password managers and browser plugins presumably at least try to scrub passwords from memory, which will save you if you forget to lock your screen or your window manager has a screen lock bypass bug (very common).
The Emacs solution will protect you if you don't use full-disk encryption and your disk falls into the wrong hands, but that applies (or should apply) to all password managers.
What am I missing?
Edit: The same applies to the solution in the article.
(defun cc () "Secrets File" (interactive) (find-file "/home/ajross/.cc.gpg"))
Launch with "M-x cc" (which is simple enough) or bind to a keystroke. Emacs will prompt you for the decryption cleanly, your distro will surely cache them with gpg-agent, and you can then just edit it and cut and paste as you like.
I'm pretty sure it's "cc" because it was originally a list of credit card numbers, but quite frankly I've been doing this so long I've forgotten.
Pass (http://www.passwordstore.org/) is password manager based on GPG that's been around for longer. It has some more tools available that are built around it and helps organize passwords as well.
I'm definitely all for multiple options, but a tool that does exactly this exists already, and uses git so you never lose history and can easily pass the store around.
A bit late to the party, but for anyone who loves pass/password-store etc, but does not like the entry names themselves being stored in the clear, I have a port of pass that fixes exactly that problem:
Yes, it even has bash completion. Its fallen a bit behind the upstream as I have not had the time to port in the new features (nor felt the need :-/). Comments/patches welcome.
This and passwordstore.org are neat. I used to do one-password-per-gnupg-file with plain GnuPG commands, and liked it quite a bit. Lately though, I've been using passwords in plaintext in a AES256 disk image with a shared long passphrase. The main advantage so far is that other family members can use the disk image work flow easily. The main disadvantage is that the disk image format is OS-platform specific. I know that KeePass probably works best for family, so we may switch to that in the future.
Does anyone know if there is a way to make something equivalent to this but using GPG's symmetric crypto instead of public crypto? This way you don't need to carry a key file around with you, just the encrypted secrets.
This is a great point. The advantage I see to using pubkey is integration with, for example, a cryptocard (https://trmm.net/Yubikey). Still, I wonder if the default should be to use gpg --symmetric instead.
The reason I asked that is because last time I messed around in this problem space I had some trouble making gpg-agent remember the password for symmetrically-encrypted stuff.
Reading in and storing the passphrase in a shell script seems like a bad idea, particularly since GPG already has a tool for reading passphrases that will cache your credentials.
[edit] I see that the passphrase is passed as a command-line argument. Aren't those viewable to other users on linux?
Thats true, but you do forget someone. If you use four-five different password spread among different sites, they will be easier to break then any generated password from keepass, pass or passwordstore.
>If anyone gets hold of your master key/pwd, they would have access to all your usernames & pwds.
You would still need access to the physical storage medium. This is either a threat or not depending on your threat model, and for most people this is simply not a threat. And tbh, if someone got a hold of your unencrypted computer you got another problem.
* git integration.
* Separate file for each secret, so that I can store the password on the first line and then other sensitive account details on subsequent lines.
* -c flag for copying passwords to clipboard (but only copies the first line of the file, so it doesn't interfere with the usecase above)
* tab completion for user account names. However, this comes at a slight cost to security -- anyone with access to your machine (or git repo) can see all of the websites / accounts for which you have a password.
* Everything happens via the file system and secrets are just gpg encrypted text files. So it's really easy to implement new utilities on top of your password store. This is true for this solution as well, but somehow having separate files for each account makes it safer to implement utilities that do account management.