[PATCH] stop using pwgen

[Antoine Beaupré]

On 2016-12-17 18:08:16, Tobias Girstmair wrote:
> I'm against it. IMHO the `pass` philosophy is to utilize UNIX tools instead of rolling one's own. 

I believe that "head", "base64" and "tr" are UNIX tools.

It's not like i implemented a password generator in pure bash (which
would be $RANDOM, and probably horrible).

> `base64` is not compatible with any password rules that require a special character. 

actually, it is, often. i have observed that base64 will yield a + or /
sign in about one out of 3 generated passwords.

so i haven't had trouble with this so far.

Jason A. Donenfeld <Jason at zx2c4.com> schrieb am 23:57 Samstag, 17.Dezember 2016:
> I'll seriously consider replacing pwgen. I didn't know it was so
> horrible. I'll investigate and make a decision.

to be fair, it is much better than it was now. i don't think there are
any known vulnerabilities in pwgen at this point, and I don't want to
make people believe that pwgen -sy is completely insecure: I have
reviewed the code and it seems fair. i just find that the *default* of
pwgen is insecure and should therefore not be encouraged. having it as a
dependency encourages it...

> I like the idea of using /dev/urandom directly, but piping it into
> base64 is a terrible idea.

why is it a terrible idea? can you be more specific?

you need a reduction function of some sort. pwgen does it by having
different set of allowed characters, which you choose with commandline
flags. pass only supports --symbols, but there's also --capitalize,
--no-vowels, --numerals, --ambiguous...

my opinion on this is that it is unnecessary: what we want is to
generate a string with a high level of entropy (base64 doesn't affect
the entropy level) that is highly "portable", that is, easy to
copy-paste.

pwgen -ys, half the time, generates a password i can't copy-paste by
simply double-clicking on it (because of symbols like [>;.]). you might
argue that you're supposed to use -c, but that is optional and there are
reasonable use-case where you can't use the clipboard to transport the
password.

so you need to take the 255 possible values from /dev/random and reduce
them to *some* space. i chose base64 because it sticks with a
conservative 6-bit range of characters that works across email, shells
and whatnot. i do not need to worry about what happens when i send a
latin1 character, LF, null or whatever /dev/random can throw at me:
there's a standard to convert arbitrary bytes into portable strings, and
I am using it.

> I've got some ideas on how to do this. I'll code a few different ones
> up and see how it goes. I'll also evaluate pwgen competitors. There
> was a nice one somebody on this list proposed a while ago.

here are the ones I know of:

* head -c $ENTROPY | base64 | tr -d '=\n'
* pwqgen - uses a wordlist and a specified entropy level
* diceware - uses a wordlist and dicerolls (or /dev/random)

the latter two are meant to be "human-memorable". i am not sure that
should be a goal of pass: the whole point of a password manager is to
*not* have to remember passwords. making passwords memorable makes them
weaker and easier to bruteforce, and should be avoided in our use case.

a.

-- 
Wherever they's a fight so hungry people can eat, I'll be there.
Wherever they's a cop beatin' up a guy, I'll be there.
If Casy knowed, why, I'll be in the way guys yell when they're mad an'
I'll be in the way kids laugh when they're hungry an' they know
supper's ready. An' when our folks eat the stuff they raise an' live
in the house they build, why I'll be there.
                        - John Steinbeck, The Grapes of Wrath