On Tue, Dec 8, 2020 at 10:27 PM Rob Landley <r...@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 >
_______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net