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.
Clever uses of pass, the Unix password manager
121–130 of 154 posts
Re: Clever uses of pass, the Unix password manager
#122Earlier quoted context omitted.
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…
> missing AGE encryption I am just curious. What makes AGE backend better than GPG one?
Age is much simpler to use in nearly every way, whether that's interactively (keys are just files!), in scripting, or in implementation.
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.
Re: Clever uses of pass, the Unix password manager
#123`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…
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…
Besides that, pass leaks metadata.
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.
Re: Clever uses of pass, the Unix password manager
#124Earlier quoted context omitted.
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…
> What obvious fault am I missing here? 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 implementatio…
> Under 'pass' all passwords conforming to chosen rules are equally likely, under your approach some are twice as likely as others.
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.
Re: Clever uses of pass, the Unix password manager
#125Earlier quoted context omitted.
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.
Did you have our key on a yubikey and that yubikey set to require a touch for every operation?
No I wasn't even aware of this feature.
I just enter my pin once and it works until I pull it out.
Re: Clever uses of pass, the Unix password manager
#126Earlier 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.
>like the need to "ultimately trust" keys before they become usable
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.
Re: Clever uses of pass, the Unix password manager
#127Earlier quoted context omitted.
Assuming a perfect RNG, but PRNGs don't have infinite state. So it's either impossible, or has a finite probability, with a finite probability for each of those cases, for an overall finite (non-zero) subjective probability of it running forever (in ideal program-space; obviously it will never run forever in real life).
No, you don't need a perfect RNG. You need anything that's not completely horrible . 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…
> 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.
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?
Re: Clever uses of pass, the Unix password manager
#128Earlier quoted context omitted.
passff and other tools like them scare me too much. That browser extension has too much power. All it would take is the author to sell it to some bad actors (or turn into one) and a lot of people will be having a very bad day. Pasting my password into a form isn't that bad, and it feels far safer.
I use a couple of little scripts to do something somewhere in the middle that I'm happy with: `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 -`.
(And if it's not obvious, that's bound to a keypress, so from the browser I just hit F4, type e.g. 'hn' and my password is entered into the focussed input area.)
Re: Clever uses of pass, the Unix password manager
#129Earlier quoted context omitted.
I wrote a tool called hunter2 [0][1] which is very similar but uses PKCS#11 modules, which may be more common than GPG since the entire US Government uses them. [0] https://chiselapp.com/user/rkeene/repository/hunter2/ [1] https://github.com/rkeene/hunter2 (mirror)
Love the name. That alone is genius, never mind all the work you've put into the tool itself.
i'd love to see the genius. what makes it so clever?
Re: Clever uses of pass, the Unix password manager
#130incredible tool, works so well with yubikeys and cross platform. use it and recommend it all the time.