[PATCH] stop using pwgen

Sun Dec 18 17:06:30 CET 2016

On Sun, Dec 18, 2016 at 4:19 PM, Antoine Beaupré <anarcat at debian.org> wrote:

> [replying to a bunch of people at once, sorry for the confusion, but i
> want to reduce the amount of emails here.]
>
> On 2016-12-17 20:44:32, Allan Odgaard wrote:
> > On 18 Dec 2016, at 6:40, Antoine Beaupré wrote:
> >
> >>> I like the idea of using /dev/urandom directly, but piping it into
> >>> base64 is a terrible idea.
> >>
> >> […]
> >> pwgen -ys, half the time, generates a password i can't copy-paste by
> >> simply double-clicking on it (because of symbols like [>;.]).
> >
> > I’ve also had minor issues with characters like backslash, apostrophe,
> > double-quote, and backtick.
> >
> > As for BSD’s base64, I am on macOS with the man page for base64
> > stating February 8, 2011 (Mac OS X 10.7) and the default is to encode
> > input, no required argument.
>
> Interesting. I was based my conclusions on:
>
> https://www.freebsd.org/cgi/man.cgi?query=base64
>
> OS X may not use the same base64 as FreeBSD? I must admit I don't have a
> BSD box on hand to test this anymore... :/
>
>
I just wanted to point out that your search ( at least the link ) includes
ports, which is where base64 is. In FreeBSD base there is b64encode and
b64decode which are synonymous with uuencode/uudecode -m

Something like the following would work
head -c 18 /dev/urandom | b64encode -r -

Best regards
Andreas

> On 2016-12-18 03:10:35, Lenz Weber wrote:
> > Please use /dev/urandom for this, not /dev/random. It is an absolutely
> > acceptable source of randomness and does not block, which will give a
> > better user experience.
> > (for better information see this talk:
> > https://media.ccc.de/v/32c3-7441-the_plain_simple_reality_of_entropy )
>
> /dev/urandom doesn't seem to exist in OpenBSD, as far as I could tell
> when i did my research, but I don't have an OpenBSD box on hand to test
> this either.
>
> /dev/random is unlikely to block for the amount of data we're extracting
> from the pool except in extreme circumstances (e.g. you're generating a
> password immediately after boot). so i don't think it's harmful to use
> /dev/random in this specific case. furthermore, /dev/random and
> /dev/urandom are links on *BSD systems that support urandom, from what i
> can understand...
>
> and yes, i watched that talk, thanks. :)
>
> > try triple-clicking - should work in most consoles ;)
>
> triple-clicking selects the whole line, so includes a newline which will
> break some sites/setups.
>
> On 2016-12-18 04:41:30, Chris Warrick wrote:
> > On 18 December 2016 at 00:40, Antoine Beaupré <anarcat at debian.org>
> wrote:
> >> pwgen has a long history of generating insecure passphrases. up until
> >> 2014 (pwgen 2.07, shipped only in Debian jessie, and Ubuntu Vivid)
> >
> > That was 2 years ago. And if you insist on using outdated distros, how
> > secure can your gpg setup be?
>
> Are you aware of pre-2014, Debian7-specific GnuPG vulnerabilities that
> we don't know about?
>
> Or am I supposed to regenerate all my primary keys every two years
> because we're in the future now?
>
> 2 years may seem like a long time for you, but for me it's very short. I
> know it's a controversial topic, but I happen to believe we're not
> supposed to rewrite and/or reinstall all our software everything every 2
> years.
>
> I build software that lasts.
>
> >> 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.
> >
> > You are introducing a dependency on GNU coreutils, though.
>
> I believe this dependency is already present in different forms
> elsewhere in the code. And if you are refering to base64 when you refer
> to coreutils, note that OS X's implementation seems to work similarly to
> GNU coreutils. I was just being careful in the commit log in that it may
> not work on other platforms, but I have (obviously) not been able to
> test every base64 implementation out there.
>
> But you are right, GNU is, litteraly, Not Unix, and deliberately so. I
> meant UNIX in the wider "unixen" sense.
>
> >> 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.
> >
> > Not nearly enough:
> > * some places may dislike + or /
> > * some places may insist on having one of a set of characters, and +/
> > may not be part of this set
> > * base64 cannot guarantee having a symbol/number/capital letter in output
> > * controlling output length of base64 is hard
>
> as others said: one algorithm can't fit them all, unfortunately. that's
> why pwgen had all those knobs, which, i should not here, are not
> actually all supported by pass.
>
> i think you are setting an impossible criterion, that is not attained by
> the current implementation:
>
> 1. pwgen -sy may also include + or / which some places may dislike (-n
>    would work around that, but then wouldn't have any special character)
>
> 2. pwgen -sy *may* have the characters some places insist on having, but
>    there's no garantee of that either
>
> 3. pwgen -sy cannot garantee having a symbol/number/capital letter in
>    output either
>
> 4. it's true that pwgen output length is easier to control than
>    base64...
>
> ... but I wouldn't call controling the length of base64 "hard". it's a
> simple calculation (+33%) that a lot of people are aware of.
>
> >> 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.
> >
> > Nonsense. If you want to copy-paste the password, then just use -c in
> > the first place. If you don’t, then there’s nothing to complain about.
>
> You may not be aware that -c sends the password to the non-default xclip
> CLIPBOARD selection, instead of the usual XA_PRIMARY. This makes it
> harder to copy-paste in terminals, for examples.
>
> > Regarding your double-click issues, please send complaints to whoever
> > wrote your terminal emulator.
>
> Somehow I don't think it's productive to open bug reports against xterm
> or rxvt because triple-click doesn't do what a password manager expects
> it to do.
>
> But then maybe that's all just me. I don't want to fight y'all for this,
> it's just a suggestion, and I see there's a lot of resistance to
> changing this, so I'll just move on to other greener fields.
>
> Anyways, Jason said he didn't like my implementation (specifically that
> "using bas64 is a horrible idea") and will work something on his own. So
> it's probably pointless to debate this further at this point.
>
> Have fun.
>
> A.
>
> --
> People arbitrarily, or as a matter of taste, assigning numerical values
> to non-numerical things. And then they pretend that they haven't just
> made the numbers up, which they have. Economics is like astrology in
> that sense, except that economics serves to justify the current power
> structure, and so it has a lot of fervent believers among the powerful.
>                         - Kim Stanley Robinson, Red Mars
> _______________________________________________
> Password-Store mailing list
> Password-Store at lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/password-store
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.zx2c4.com/pipermail/password-store/attachments/20161218/a6aa6afa/attachment-0001.html>