[conspire] Password permutations (was: Correction)

[Michael Paoli]

> From: "Rick Moen" <rick at linuxmafia.com>
> Subject: [conspire] Password permutations (was: Correction)
> Date: Mon, 30 Mar 2020 13:19:55 -0700

> The above sort of mindless approach, however, encourages the use of
> line-noise-resembling passwords, e.g., pseudo-randomly generated ones.
> Techies such as Michael P. often gravitate towards those, blithely
> ignoring the obvious disadvantage that they are pretty much impossible
> to memorise and nearly impossible to type accurately.

Hmmm, maybe for some/many/most?  But I have no particular difficulty
memorizing and accurately typing such "line noise" passwords.
Not only do I commonly memories passwords such as (like, not real
passwords):
c4y1*%`'
u!RzEVt4
cnPmG3w`
but (maybe years of practice?) I find them probably easier to memorize and
accurately type, compared to long word(ish) based passphrases and such
containing similar levels of entropy.

Your mileage may, and probably will, vary.  ;-)

Oh, and character sets ...
for at least some passwords (used to do it more commonly),
not only isgraph and isprint ASCII characters,
but most all ASCII characters - including most of the
control characters.  But alas, many(/more) of those can be
problematic with GUI interfaces, and none of the control
characters work as part of passwords on any web input form I've
yet to encounter.  And, speaking of problematic characters in
Linux(/Unix/BSD) passwords, there are even a few isgraph
characters which can be problematic (and one both problematic and
useful too!).  Notably these: #@\
# is ancient default erase character - in some (notably Unix) contexts,
one can still bump into that.  Likewise, @, ye olde ancient default
kill character.  And \ - double-edged sword.  Escape character.
So ... it does also depend upon context, but in many cases,
for a literal \ in password, one may need type \\,
but also usefully, in many cases, \X where X is some character that
might otherwise be problematic, can be used to have X as literal part
of password, whereas X might not otherwise work.  However, for about
99.9% (or more) of users - and even sysadmins, generally "best"
(safest) to avoid control characters, and also to be 100% "safe",
also avoid the #@\ characters in passwords.  So, just isprint
characters, less those three (#@\), and one is quite safe for
using those in most any Linux/Unix/BSD context as/for/in/comprising
login passwords.  Sometimes other passwords may have various and/or
additional limitations ... but that's another matter.
Oh, and too, if one needs to (securely, hopefully!) transmit a
(temporary!?) password via some means where someone will read
it before using (or see it and copy/paste), typically best in such
circumstances to also avoid the space character.  But of course space
is itself fine in a password (in most contexts).  Though, too, some
would argue, space character is more vulnerable due to the relatively
different sound of it when being typed.  So ... there may be considerations
as to when/where/how it would or might be typed, as to whether that's
a (significant?) concern or not.

So, yes, ... Linux(/Unix/BSD) passwords ... can contain generally any
ASCII characters, except ASCII null, and often disallows NL (or may
have no way to enter it into literal password).
"Of course" lots of allowed characters - especially control
characters, can be difficult/tricky, or even "impossible" to enter,
at least for certain interfaces.  So, e.g., having CR in one's
password ... one would typically need to proceed that with \ when
entering to defeat the typical mapping of CR to LF which is then
generally handled as EOL to terminate password entry.  And if one is on
a GUI - yeah forget it for even more (if not all) control characters.
E.g. ... typical X session login (at least old school). While
control-R might work fine from CLI/terminal, control-R would typically
do things to one's X login screen - and without a means to escape that
behavior.  So ... don't go *too* crazy with password characters.
But something(s) like:
c4y1*%`'
u!RzEVt4
cnPmG3w`
not a problem for Linux(/...) OS passwords or entering (though debatable
how useful/harmful/feasible for the mere mortal humans).

Also, one of the problems with humans picking (shortish) passwords,
they also tend to not pick a rich nor random set of characters - so
that greatly reduces the entropy - and thus are more common - and
weaker passwords.  Countermeasures are (much) longer and/or
more varied and random(ish) set of characters and ordering.
Many "password construction rules" are intended to introduce more
entropy, but often they're only marginally effective at that.
Heck, sometimes I've seen password rule thingies that were
stupid and weakened passwords!  E.g. once upon a time, dealt with
one that would reject passwords if they contained a correctly
spelled word (delimited by start/end of password or non-word
characters).
So, I might have a password like:
xp",^Na^E;
where ^N and ^E are control characters ... and the stupid
disallow English words rule, would see, between the control
characters, the word "a", and thus reject the password for
containing a correctly spelled word.  Well, tossing out all
such passwords containing a correctly spelled word (and it
would do case-insensitive matching check), would rather significantly
reduce the keyspace of available passowrds (okay, sure, it'd also
reject some stupid weak ones too - but likewise it also would disallow
many good strong ones also).

Oh, and while I'm on my password soapbox ;-) - some pet peeves:
The days of limiting passwords to some short length should be long
dead.  Allow quite long passwords - at least up to some reasonable length
like 64 (or 128 or more!) characters.  You're gonna store a secure
salted hash anyway, not the dang password, so don't limit the
input length (or at least allow for quite long).
On whatever I enter to set the password, and later enter to authenticate,
it needs be processed the same, so what I enter and set the password to,
also works for the password to authenticate.  Way too many - most notably
damn web sites - get this wrong.  They'll truncate one, but not the
other, or silently truncate all characters after some particular
character.  E.g. like I'll put in a nice long secure password that contains
the character ";", only to later find out I have a 3 character password,
as the 4th character of what I set my password to was ";", and that and
all the following characters were silently dropped when I set the password.
Yeah, don't do that.
Allow at least all isgraph (and probably all isprint) ASCII characters
in password.  Failing to do that is stupid - you properly encode the stuff
for handling, right? ... right?  And consistently?  And dang, if there
are any characters you can't accept, clearly state exactly what those
characters are right where the user is (re)setting their password - and
be damn consistent about it - make what's shown, and the actual behavior
consistent.  And too (did I say it already?) don't silently truncate  
passwords.
I'm sure there's more, but I'll get off my soapbox for now.