Clever uses of pass, the Unix password manager
vitalyparnas.com
vitalyparnas.com
It's is a bash script that makes it convenient and easy to use gpg2, the OpenPGP encryption tool. Frankly, I'm kind of shocked at how difficult it is to use the gpg2 command line utility. Clearly it's an extremely powerful tool, but it's written with the assumption that the user has a very deep understanding of how encryption and key signing work. To use `pass` effectively you should have a basic understanding of encryption, but unlike gpg2 you don't need to dedicate a week to grok the manpage.
Before I start working on next project... Do you recognize any mobile app, which could replace PasswordStore app for Android [0] but with AGE support?
[0]: https://github.com/android-password-store/Android-Password-S...
[1]: https://github.com/android-password-store/Android-Password-S...
I am just curious. What makes AGE backend better than GPG one?
I'm still sticking to gpg for the foreseeable future, but between age and sequoia[1] I'm hopeful that things will soon be much easier to use.
- It works smoothly with SSH keys (generated from ssh-keygen), which are perfectly recognized by possibly any developer.
- No need for external client, such as GpgWin/Kleopatra for Windows.
- Embed-able in Rust[0] and Go[1] (there are libraries), no need to call `gpg --decrypt ...` from the command line.
- Encrypted files by pass and keys are smaller. I guess it is thanks to ecliptic-curve encryption.
Mmm. I don't think so. Recent OpenSSH includes file signatures not encryption.
Did you have to do that manually at one time? All the keypairs that I make start out that way when created.
When creating a keypair for pass all you have to do is generate the key using defaults while remembering a bit of the user ID to give to pass.
I think it would be a great addition if pass could actually automate this by storing all relevant public keys internally.
In general I think you are supposed to only have a one or a few "ultimately trusted" keys and then distribute that trust by signing the rest. So once you change the trust on one key the trust distributes automatically.
Seems like pass wants to use the Unix philosophy of “do one thing well” so it relies on gpg for encryption instead of rolling its own.
If your passwords are the only part of your password manager you think are secret, then you're probably not considering the utility of an enumeration of all your network handles. Mine aren't very interesting, but I wouldn't post that on GitHub, even in a private repo.
I love pass and use it. But when I need to carry my password database around, I don't rely on pass alone - I throw the pass database in a Veracrypt container. That way if my flash drive is stolen, it's just an encrypted blob.
[0] https://chiselapp.com/user/rkeene/repository/hunter2/ [1] https://github.com/rkeene/hunter2 (mirror)
But simple and user-friendly UX design is hard. As a user of `pass`, I'm grateful for what I have.
https://www.openbsd.org/papers/bsdcan-signify.html
> There are no key servers for signify. No web of trust. Just keys.
I'm not sure how that would work for quorum publishing, which guards against any single set of credentials being compromised by requiring multiple trusted signatories. The idea is that packages are signed by multiple identities, and if as a downstream user, you trust enough of those identities to form a quorum (2, or 3, or some score-based criteria), then you consider the release trustworthy enough to accept automatically. (The underlying theory is just multifactor auth.)
Downstream users need some way of determining how to trust keys, and that mechanism should be decentralized. This seems to be at odds with the priority the BSD authors place on key rotation:
> After each release of OpenBSD, we generate a new key pair for the release after next. That's plus two. For example, after 5.6 was released, keys for 5.8 were generated. This way, the 5.8 keys are then included in the 5.7 release. So, if you upgrade every release, you will have an unbroken chain of keys back to your initial installation.
So it sounds like there's a single set of keys for each release, which has to be kept safe. I'm sure that the OpenBSD folks take great care, but the idea of quorum publishing is to require multiple factors so that an attacker has to compromise multiple identities to spoof a release.
To fix this as well pass it into curl as a config via eg: curl [...] -K- <<< "--header auth:$(pass mysecret)"
What if non-root could see their own processes in detail, but only the program name for other users' processes?
Would that break a lot of other things?
sudo mount -o remount,hidepid=1 /proc
At which point you might as well ask why do you need to see other users processes at all? And indeed, that is an option in grsec. I don't think it causes any major breakage, but there are probably some xkcd #1172 sort of things that break.
edit: apparently there is nowdays also options in mainline for that too: https://pipo.blog/articles/20130930-hidepid-process-hiding and also possibly with selinux?
https://www.cyberciti.biz/faq/linux-hide-processes-from-othe...
Biggest surprise is that people can't run top/ps to see where load is coming from, but that aside I never noticed any particular downsides.
Individual units can opt-in to this behaviour with the ProtectProc= option though. But I don't think there's currently a good way to apply it to users' interactive processes.
Bind this script to a keybinding, and it will load all your passwords into dmenu and let you type the first few characters of a website name, then copy the password to the clipboard. No CLI needed.
Also, Password Store by Harsh Shandilya on Android is a wonderful little tool. Too pity is has only two sponsors on Github.
Reason is that you can use e.g. YubiKey to unlock individual entries on touch, this means that you can't lose whole password database on ransomware attack, (unless the ransomware has been there for a very long time).
Filippo Valsorda wrote about this: https://blog.filippo.io/touch-to-operate-password-store-yubi...
With YubiKey you can make the GPG private key on offline machine and upload it to YubiKey. This way you can always have a offline backup of your private key, and thus you can backup your password database too.
Could also disable the touch to decrypt feature while you performed the rekey?
Disabling touch is another option if you need to do a large batch of operations and are comfortable that your machine is secure.
I'd highly recommend using the `fix` option instead of `on` to make sure it can't be disabled.
Edit: oh. Adding a new key, not password. I see how I misread.
I just enter my pin once and it works until I pull it out.
I'd suggest trying 'on' before 'fix', but then switching to 'fix' for the extra security it provides.
export SECRET_API_TOKEN={{ pass "api/token" | quote }}
https://askubuntu.com/questions/354915/quote-command-in-the-...
[1] https://masterminds.github.io/sprig/strings.html [2] https://pkg.go.dev/text/template
Works well enough for us.
1. https://medium.com/@davidpiegza/using-pass-in-a-team-1aa7adf...
I'd like to see something similar but with age support .
Pasting my password into a form isn't that bad, and it feels far safer.
Instead of clicking "Add to Firefox", you can right-click and "Save Link As..."
`fzf-dmenu` spawns an alacritty window running fzf over given input.
`pass-dmenu` calls the former with available password names; takes the result (if any) and decrypts & types it with `pass show $result | xdotool type --file -`.
pass lets you use GPG-smartcards, and many of those (such as Yubikeys) will let you enforce touch-policies for signing/encruption.
As a combination of both these however, I must touch my Yubikey every time I pull a new docker image.
Another cool use-case is that I use the terraform-pass-provider to save secrets for my personal terraform project.
This makes it easy to fill in card info online using the same password tools you're already using (passmenu, rofipass, etc.), without needing to go find your wallet, or rely on your browser's form auto-fill database (and worry about hidden fields attempting to exfiltrate that auto-fill data).
I'm tempted to use `pass` to store TOTP seeds as well, but this seems like a bad idea because you'd be putting both factors in one place. Maybe a separate pass db stored offline or something...
kubectl create secret generic -o yaml --dry-run \
--from-literal "foo=$(pass show foo)"
foo | kubectl apply -f -
The next guy ripped it out and replaced with Vault and none of the passwords have been rotated since.
Instead, stuff the creds into pass, and since dotenv leverages bash, you can put substitutions in your .envrc file. Bonus, now that the creds are in a personal secured repo, you don't have to go hunting for the creds every time you want to spin up a new dev machine. (you do unfortunately still have to migrate your .envrc, I tried writing git tooling to make it easier but I could never find a convenient place to store them. I have ideas to extend git to try out the next time I want to iterate on this)
This does require your app to be properly configurable with environment variables, meaning if an envvar is present, it should override all other settings. Envvars don't get set by accident so they should be treated as the ultimate settings. This is usually the case with most frameworks but I've run into Node apps where this wasn't the case. Maddening.
In wayland you can pipe the password into wl-copy -o so it will only be pasted once then disappear.
In Xorg you'd need a callback after running pass that runs xclip -i /dev/null some time after the password is copied.
There is no good solution to this in Linux that does not involve discipline.
vault_password_file = tools/vault.sh
echo -n $(pass infrastructure/ansible-vault)
[1]: https://docs.ansible.com/ansible/latest/collections/communit...
Stellar. Absolutely stellar piece of software. Always does exactly what I want it to, never gets in my way ever!
• opens you up to timing attacks on your PRNG (unlikely to be a problem in real life, but you never know)
• might run forever
;)
In practice, it doesn't matter, I agree.
Remember, we're not trying to read a whole password from the device, just one matching byte at a time. So, even if our password character set is a single character (pass will let you do that, but obviously you should not use such passwords in real life) we're talking about statistically 1 out of 256 bytes matches or else our PRNG is useless.
You correctly observe that the PRNG has finite state, but its state isn't so tiny that it only emits a handful of the 256 possible bytes before getting back to where it started, nobody would use such a busted algorithm.
RC4 is considered broken and unusable because the keystream is biased and thus distinguishable from random - to the extent that if you read a few million bytes from it you can detect the bias, but you're asking us to imagine that the random device has a PRNG many orders of magnitude worse in order for this to have any effect at all.
If the PRNG always loops through all possible states, then sure. But if there's a possibility, however small, of it getting stuck in a small loop, very rarely?
We already went around this particular "small loop" so I'm guessing you aren't learning anything from repeating it. That would be a lousy design for a PRNG, so, nobody does that.
That is, for most people it is well outside the attack surface that they need to care about.
tr -dc "0-z" < /dev/urandom | head -c10For example I should like a 1-character password, from the alphabet of A, B and C.
So that's 2 bits. We read two bits (awkward, the random device is of course byte oriented). Now, we have a 2-bit value and we're trying to pick A, B or C. But what do we do with the 4th possibility from our 2-bit value?
We could decide too bad we'll treat it as A (or B, or C) anyway, but now we've introduced a non-random bias to our supposedly random password.
The non-horrible option is to throw away this possibility and read two more bits hoping for a different outcome. The exact same algorithm pass uses, except you've added the extra complexity of reading less than one byte at a time from the device...
Well, let's begin with the fact it's worse. You argue it's not "much" worse, but it is clearly worse not the same. Under 'pass' all passwords conforming to chosen rules are equally likely, under your approach some are twice as likely as others.
But then the other characteristic is simplicity. Using 'tr -cd' is, by my counting, five characters. How big is your best implementation of this supposedly "even simpler" but worse solution?
But they're passwords. At most half of the passwords will have different probability than the rest which means that you're still left with a staggering number of un-brute-forceable passwords. Two to the power of ninety nine is practically indistinguishable from two to the power of one hundred.
By the way, if you're still obsessed about completely equal probabilities here, you can just drop the whole sequence of bits if it's larger than the number of alternatives when interpreted as a binary number and fetch a new one. It seems to me that the expected value of number of bits consumed for such a process won't exceed twice the number of bits that are technically necessary (because the probabilities of individual numbers of attempts are a geometric sequence with a factor of at most 0.5 summing to exactly 1, which would have an expected value of 2), which is around 12.5 bits per character. With a filtration like tr -dc "0-z" mentioned below you'll consume roughly 27.3 bits per character on average. So "better" is a subjective term here; one solution may be simpler to write in a shell command line, another consumes much less entropy. If you're deciding what to do, you need to weigh your criteria properly if you have more of them. You may very well have different criteria than I do; that happens.
> Using 'tr -cd' is, by my counting, five characters
I probably wouldn't use this in the first place because it requires a subprocess and a binary that I might not have on some computers. So by my counting this could be hundreds of kilobytes of extra code. Division with a remainder is most likely something you already have in your standard library regardless of whether you use it or not.
To the extent that it could mean something to "consume" entropy from the random device they're both outputting the same size of password and so they're consuming roughly the same amount of entropy. Assuming the random device works as intended this would be a distinction that makes no difference anyway.
> a binary that I might not have on some computers
A binary that's included in the Linux Standard Base. Which computers don't you have it on?
> this could be hundreds of kilobytes of extra code
More like a few dozen kilobytes, although of course on tiny Linux systems it's bundled into something like busybox so much less.
> Division with a remainder is most likely something you already have in your standard library regardless of whether you use it or not.
The shell, which is what pass is written for, does have division with a remainder, but it cannot do this operation on 96-bit integers. So now you've added another constraint "rewrite this software in a language which has 96-bit integers, or more if longer passwords are allowed" [Hint: Longer passwords are very much allowed in pass]
So far what you've achieved is to show that this is trickier than you thought, yet produces worse results. Again, this is why I like what Jason did here.
I'm using some Windows computers. But for example I can use (and often do) a dumped SBCL binary on them just fine, even on those where I can't install anything.
Works wonderfully and with OTPauth also.
Run a bare git repo on your own network and there is no reason to use Bitwarden.
Edit - and for those that are in AWS, you can use pass along with aws-vault to keep your ~/.aws creds in check. https://github.com/99designs/aws-vault
https://github.com/roddhjav/pass-import
maybe you can "bridge it" with bitwarden-cli via some export/import commands or may as well use bitwarden-cli directly (but i find the pass ui much bettwer than bw cli command)
Just setup isync yesterday. So close to having freedom to move from Google whenever I want