<html><head></head><body><div class="ydp5fddea8eyahoo-style-wrap" style="font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:13px;"><div></div>
        <div dir="ltr" data-setdir="false">I always think about the key strokes when creating a password.  Even if I think it will be possible to remember, some combinations of keys are easy to mess up and since you can't see when typing the password.  <br></div><div dir="ltr" data-setdir="false">Furthermore, I have learned to my chagrin that some things which are easy to type on a full keyboard don't work well on a small screen, especially if you have to jump between letters and numbers and uppper/lower case.</div><div dir="ltr" data-setdir="false"><br></div><div><br></div>
        
        </div><div id="ydp75f213e0yahoo_quoted_7723226546" class="ydp75f213e0yahoo_quoted">
            <div style="font-family:'Helvetica Neue', Helvetica, Arial, sans-serif;font-size:13px;color:#26282a;">
                
                <div>
                    On Tuesday, April 14, 2020, 2:19:31 AM PDT, Michael Paoli <michael.paoli@cal.berkeley.edu> wrote:
                </div>
                <div><br></div>
                <div><br></div>
                <div>> From: "Rick Moen" <<a shape="rect" href="mailto:rick@linuxmafia.com" rel="nofollow" target="_blank">rick@linuxmafia.com</a>><br clear="none">> Subject: [conspire] Password permutations (was: Correction)<br clear="none">> Date: Mon, 30 Mar 2020 13:19:55 -0700<br clear="none"><br clear="none">> The above sort of mindless approach, however, encourages the use of<br clear="none">> line-noise-resembling passwords, e.g., pseudo-randomly generated ones.<br clear="none">> Techies such as Michael P. often gravitate towards those, blithely<br clear="none">> ignoring the obvious disadvantage that they are pretty much impossible<br clear="none">> to memorise and nearly impossible to type accurately.<br clear="none"><br clear="none">Hmmm, maybe for some/many/most?  But I have no particular difficulty<br clear="none">memorizing and accurately typing such "line noise" passwords.<br clear="none">Not only do I commonly memories passwords such as (like, not real<br clear="none">passwords):<br clear="none">c4y1*%`'<br clear="none">u!RzEVt4<br clear="none">cnPmG3w`<br clear="none">but (maybe years of practice?) I find them probably easier to memorize and<br clear="none">accurately type, compared to long word(ish) based passphrases and such<br clear="none">containing similar levels of entropy.<br clear="none"><br clear="none">Your mileage may, and probably will, vary.  ;-)<br clear="none"><br clear="none">Oh, and character sets ...<br clear="none">for at least some passwords (used to do it more commonly),<br clear="none">not only isgraph and isprint ASCII characters,<br clear="none">but most all ASCII characters - including most of the<br clear="none">control characters.  But alas, many(/more) of those can be<br clear="none">problematic with GUI interfaces, and none of the control<br clear="none">characters work as part of passwords on any web input form I've<br clear="none">yet to encounter.  And, speaking of problematic characters in<br clear="none">Linux(/Unix/BSD) passwords, there are even a few isgraph<br clear="none">characters which can be problematic (and one both problematic and<br clear="none">useful too!).  Notably these: #@\<br clear="none"># is ancient default erase character - in some (notably Unix) contexts,<br clear="none">one can still bump into that.  Likewise, @, ye olde ancient default<br clear="none">kill character.  And \ - double-edged sword.  Escape character.<br clear="none">So ... it does also depend upon context, but in many cases,<br clear="none">for a literal \ in password, one may need type \\,<br clear="none">but also usefully, in many cases, \X where X is some character that<br clear="none">might otherwise be problematic, can be used to have X as literal part<br clear="none">of password, whereas X might not otherwise work.  However, for about<br clear="none">99.9% (or more) of users - and even sysadmins, generally "best"<br clear="none">(safest) to avoid control characters, and also to be 100% "safe",<br clear="none">also avoid the #@\ characters in passwords.  So, just isprint<br clear="none">characters, less those three (#@\), and one is quite safe for<br clear="none">using those in most any Linux/Unix/BSD context as/for/in/comprising<br clear="none">login passwords.  Sometimes other passwords may have various and/or<br clear="none">additional limitations ... but that's another matter.<br clear="none">Oh, and too, if one needs to (securely, hopefully!) transmit a<br clear="none">(temporary!?) password via some means where someone will read<br clear="none">it before using (or see it and copy/paste), typically best in such<br clear="none">circumstances to also avoid the space character.  But of course space<br clear="none">is itself fine in a password (in most contexts).  Though, too, some<br clear="none">would argue, space character is more vulnerable due to the relatively<br clear="none">different sound of it when being typed.  So ... there may be considerations<br clear="none">as to when/where/how it would or might be typed, as to whether that's<br clear="none">a (significant?) concern or not.<br clear="none"><br clear="none">So, yes, ... Linux(/Unix/BSD) passwords ... can contain generally any<br clear="none">ASCII characters, except ASCII null, and often disallows NL (or may<br clear="none">have no way to enter it into literal password).<br clear="none">"Of course" lots of allowed characters - especially control<br clear="none">characters, can be difficult/tricky, or even "impossible" to enter,<br clear="none">at least for certain interfaces.  So, e.g., having CR in one's<br clear="none">password ... one would typically need to proceed that with \ when<br clear="none">entering to defeat the typical mapping of CR to LF which is then<br clear="none">generally handled as EOL to terminate password entry.  And if one is on<br clear="none">a GUI - yeah forget it for even more (if not all) control characters.<br clear="none">E.g. ... typical X session login (at least old school). While<br clear="none">control-R might work fine from CLI/terminal, control-R would typically<br clear="none">do things to one's X login screen - and without a means to escape that<br clear="none">behavior.  So ... don't go *too* crazy with password characters.<br clear="none">But something(s) like:<br clear="none">c4y1*%`'<br clear="none">u!RzEVt4<br clear="none">cnPmG3w`<br clear="none">not a problem for Linux(/...) OS passwords or entering (though debatable<br clear="none">how useful/harmful/feasible for the mere mortal humans).<br clear="none"><br clear="none">Also, one of the problems with humans picking (shortish) passwords,<br clear="none">they also tend to not pick a rich nor random set of characters - so<br clear="none">that greatly reduces the entropy - and thus are more common - and<br clear="none">weaker passwords.  Countermeasures are (much) longer and/or<br clear="none">more varied and random(ish) set of characters and ordering.<br clear="none">Many "password construction rules" are intended to introduce more<br clear="none">entropy, but often they're only marginally effective at that.<br clear="none">Heck, sometimes I've seen password rule thingies that were<br clear="none">stupid and weakened passwords!  E.g. once upon a time, dealt with<br clear="none">one that would reject passwords if they contained a correctly<br clear="none">spelled word (delimited by start/end of password or non-word<br clear="none">characters).<br clear="none">So, I might have a password like:<br clear="none">xp",^Na^E;<br clear="none">where ^N and ^E are control characters ... and the stupid<br clear="none">disallow English words rule, would see, between the control<br clear="none">characters, the word "a", and thus reject the password for<br clear="none">containing a correctly spelled word.  Well, tossing out all<br clear="none">such passwords containing a correctly spelled word (and it<br clear="none">would do case-insensitive matching check), would rather significantly<br clear="none">reduce the keyspace of available passowrds (okay, sure, it'd also<br clear="none">reject some stupid weak ones too - but likewise it also would disallow<br clear="none">many good strong ones also).<br clear="none"><br clear="none">Oh, and while I'm on my password soapbox ;-) - some pet peeves:<br clear="none">The days of limiting passwords to some short length should be long<br clear="none">dead.  Allow quite long passwords - at least up to some reasonable length<br clear="none">like 64 (or 128 or more!) characters.  You're gonna store a secure<br clear="none">salted hash anyway, not the dang password, so don't limit the<br clear="none">input length (or at least allow for quite long).<br clear="none">On whatever I enter to set the password, and later enter to authenticate,<br clear="none">it needs be processed the same, so what I enter and set the password to,<br clear="none">also works for the password to authenticate.  Way too many - most notably<br clear="none">damn web sites - get this wrong.  They'll truncate one, but not the<br clear="none">other, or silently truncate all characters after some particular<br clear="none">character.  E.g. like I'll put in a nice long secure password that contains<br clear="none">the character ";", only to later find out I have a 3 character password,<br clear="none">as the 4th character of what I set my password to was ";", and that and<br clear="none">all the following characters were silently dropped when I set the password.<br clear="none">Yeah, don't do that.<br clear="none">Allow at least all isgraph (and probably all isprint) ASCII characters<br clear="none">in password.  Failing to do that is stupid - you properly encode the stuff<br clear="none">for handling, right? ... right?  And consistently?  And dang, if there<br clear="none">are any characters you can't accept, clearly state exactly what those<br clear="none">characters are right where the user is (re)setting their password - and<br clear="none">be damn consistent about it - make what's shown, and the actual behavior<br clear="none">consistent.  And too (did I say it already?) don't silently truncate  <br clear="none">passwords.<br clear="none">I'm sure there's more, but I'll get off my soapbox for now.<div class="ydp75f213e0yqt4813569250" id="ydp75f213e0yqtfd27210"><br clear="none"><br clear="none"><br clear="none">_______________________________________________<br clear="none">conspire mailing list<br clear="none"><a shape="rect" href="mailto:conspire@linuxmafia.com" rel="nofollow" target="_blank">conspire@linuxmafia.com</a><br clear="none"><a shape="rect" href="http://linuxmafia.com/mailman/listinfo/conspire" rel="nofollow" target="_blank">http://linuxmafia.com/mailman/listinfo/conspire</a><br clear="none"></div></div>
            </div>
        </div></body></html>