[Toybox] [New Toy] pwgen

[enh]

On Tue, Dec 8, 2020 at 10:27 PM Rob Landley <rob at landley.net> wrote:

> On 12/8/20 12:38 PM, enh wrote:
> >     In any case, it's a complete rewrite of the password generation
> logic, although
> >     that's now a drop-in replacement for a tiny code block. If you think
> it's worth
> >     doing, I can do it...
>
> Looking at the history, the original description of this command back in
> 1988
> was "random but pronounceable password generator":
>
>   https://groups.google.com/g/comp.sources.misc/c/7nvaNzbjMXk
>
> So... maybe? But not right now, I've reopened the shell can of worms and am
> hip-deep again at the moment. (The set command changes the positional
> parameters
> and the allocation lifetime means I need function context to stick a
> delete list
> on, which I need to implement function calls anyway so might as well do
> that now...)
>
> > i have no opinion on that, not having used either, but did think it
> might be
> > worth changing the docs to match reality:
> >
> > -      -s  --secure                      Generate more random passwords.
> > +      -s  --secure                      Generate random passwords
> (default).
>
> I already checked in a commit that made -s disable the two high bit checks
> to
> make punctuation and capital letters occur less often. The result is more
> random
> (and less human readable) passwords.
>
> Another thing the "here's a screen full of passwords" does is let you pick
> one
> you like. I admit our code is aesthetically inferior (for native english
> speakers), but it's small and simple.
>
> > i see there's also a secpwgen(1) but that seems to be slightly different
> again?
>
>   $ man secpwgen
>   No manual entry for secpwgen
>
> I'd rather not go down that rathole, thanks. :)
>

huh, from the fact that pwgen(1) refers to secpwgen(1) [at least in the
copy i found on the web] i assumed they were related. (none of my systems
have either.)


> Should the command exist: "make bloatcheck" puts this at 693 bytes on
> x86-64,
> which is reasonable for what it does. A user with a use case asked for it,
> it's
> an existing command (dating back to 1988 and currently in version 2.07 of
> the
> rewrite by a kernel developer), and I can see an embedded system wanting to
> "pwgen -1" and then spit the wireless password out on a tiny LCD or
> similar.
>
> Should we try to improve the output: these days passwords smell like a PIN
> for 2
> factor authentication to me.


yeah, the only place i've seen these "human friendly" passwords used
personally is as one half of two-factor systems.


> An ATM hands out MONEY if you stick in your card
> and enter just a 4 digit PIN, and while we could make PINs longer and add
> letters and punctuation the POINT is just to alert a human and flag the
> card as
> maybe stolen if you do it wrong 3 times in a row. (3 in 10000 chance of
> guessing, and it's got video cameras to see who tried.) Even when the
> second
> factor is just "user account name" plus "IP address you're trying from",
> that's
> enough to flag multiple consecutive failed attempts (and ddos is also easy
> to
> spot), and brute forcing just 8 lower case letters is 1 in 209 billion. No
> password protects from a key logger and if somebody gets an /etc/shadow
> file to
> brute force at their leisure without attempt ratelimiting I doubt it
> matters how
> long/complex the passwords are?
>
> A "be nicer to humans" aesthetic argument makes sense to me, but is also
> almost
> by definition bikeshedding. A "be more secure" argument is above my pay
> grade. I
> already switched random sources, beyond that I expect the security guys to
> tsk
> sadly, tell you to use an ssh key, get a USB dongle on top of that, and
> change
> your biometric data frequently.
>

indeed.


> Rob
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20201208/0ef7a6a4/attachment-0001.htm>