111–120 of 154 posts
Recently used pass to share passwords between colleagues (3 in total). Files are encrypted against three different GPG public keys and shared via Git. Works well enough for us.
Earlier quoted context omitted.
As a user, I also often feel like `gpg` brings a lot of annoying accidental complexity to `pass`, (like the need to "ultimately trust" keys before they become usable) but on the other hand it enables integration with hardware tokens like Yubikeys and in extension mobile devices (via openkeychain) that as far as I know wouldn't be possible with a more modern age-based backend.
SSH has included file encryption for a few versions now, and iirc supports yubikeys — probably would be more useful a backend than age.
Mmm. I don't think so. Recent OpenSSH includes file signatures not encryption.
Earlier quoted context omitted.
Correct. Gopass has very early age support. It fully works but the UX is not great (yet).
Oh dammit. I have stopped using Gopass and rewrote pass just for that reason - missing AGE encryption. At least I have learned something new and I feel I have better UI - fuzzy finder instead of their TUI. However, big kudos to Gopass team for awesome work and really useful tool. Before I start working on next project... Do you recognize any mobile app, which could replace PasswordStore app for Android [0] but with A…
I am just curious. What makes AGE backend better than GPG one?
`pass` was written by Jason Donenfeld, the developer who gave us WireGuard. 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…
Earlier quoted context omitted.
Let's try it. For 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…
With a non-trivial (= much more realistic) length of your random number, how do you ever lose more than a fraction of a bit of entropy this way? Let's say you want a 16-character alphanumeric (a-zA-Z0-9) password. log₂ 62¹⁶≈95.267. Let's say you pull 96 bits and ignore the imbalance. Then you have 2×62¹⁶-2⁹⁶=16116640899382729306982711296 options with a probability of 2×2⁻⁹⁶ and 2⁹⁶-62¹⁶ options with a probability of…
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?
Earlier quoted context omitted.
As much as I love Jason Donenfeld's work, I tried to use pass and the gpg requirement just rubbed me the wrong way. It's basically just gpg-encrpyting a text file and unlocking that along with some wrappers for basic password manager functionality (I guess most important is clipboard functionality and clearing it automatically after some seconds), but somehow that seems like a weak point to me. It's a whole lot of re…
As a user, I also often feel like `gpg` brings a lot of annoying accidental complexity to `pass`, (like the need to "ultimately trust" keys before they become usable) but on the other hand it enables integration with hardware tokens like Yubikeys and in extension mobile devices (via openkeychain) that as far as I know wouldn't be possible with a more modern age-based backend.
Earlier quoted context omitted.
If you are using GPG keys and have the master key backed up somewhere you can fairly easily use that on an offline machine to add the new key to the full batch of password files without needing to perform a million button presses.
Been there and done that. People are backing up those keys, right? Could also disable the touch to decrypt feature while you performed the rekey?
I'd highly recommend using the `fix` option instead of `on` to make sure it can't be disabled.
Earlier quoted context omitted.
It also has a few downsides: Adding a new key requires re-encrypting every entry. Touching your yubikey hundreds of times gets old, fast.
Touching? What? I did this recently and it's very simple thanks to pass init. I now have two keys, my old one and my new one that is on my yubikey.
For those interested in pass for use in shell script based contexts, you may also find encpass.sh ( https://github.com/plyint/encpass.sh ) useful. This is a simple tool I wrote (a while ago now) to encrypt/decrypt secrets and store them in a manner very similar to pass, except it uses OpenSSL instead of GPG. Since it is also just a shell script and it's only real dependency is OpenSSL, then it can be used in a wide a…
The stdout from `pass` is awful, even for copy-pasting. OTOH, gopass [1], an otherwise 100% compatible drop-in replacement does the job much better and has some neat collaborative features as well. [1] https://github.com/gopasspw/gopass