[sf-lug] stupid password sites (reinventing the wheel, poorly)

Michael Paoli Michael.Paoli at cal.berkeley.edu
Sat Oct 8 07:59:27 PDT 2016


Well, that same stupid site also limits password length to
16 characters, otherwise I'd use a longer password.

It also requires at least one special character
(and at least one each of: an upper case letter,
a lower case letter, a decimal digit) ... oh,
and the first character *must* be a letter.
(gee, and by how much are they going to reduce
the keyspace of valid passwords?  Why not go
all the way, and just say the first character
must be a letter, and it must be lowercase "d",
the second character must be a digit, and it
must be 6, the third character ...)
It also semi-, but not so -, "helpfully"
displays what special characters it allows ...
but it's not correct ... one has to try over and over, tossing
out special characters and dumbing down the password until
it finally accept such.  Some such dumb sites I just will,
in frustration, give it a pure alpahnumeric, or pure alpha
password ... but this one insists upon at least one special
character, but its diagnostics and information about what
is and isn't allowed, and what's rejected and why, is total
cr*p.
l+zZu3q55`$8!{dk
... a dictionary word my *ss.  Nope.  Not before I
first attempted to set that password - not unless they've
also got a time machine, but obviously their
technology isn't nearly that good - they've not
even mastered last century technology, let
alone this or next.

So yes, still far too many sites do really stupid and
annoying things with passwords and requirements, handling,
diagnostics/(mis)information, etc.

Another typical highly annoying misbehavior:
Enter the password, enter it again for verification,
... then it doesn't work, ... ever.  Why?
Typically because they screw up - and the
code that handles setting/changing the password
doesn't identically handle the input password the
same way as the code that uses the password for
verification ... so, e.g. they get encoded
slightly differently - or one encoded, and one
not, before being hashed ... and henceforward
same password will never "match" and will never
successfully authenticate.  Most every time I
encounter that, it's some non-alpha-numeric
character that they screw up on.  Such also
often indicates they've got vulnerabilities
in their code.  E.g. I put in a
20 character password - it accepts it to
change/set it, but not to authenticate.
So I try truncating the password ...
19 characters, ... 18 characters ...
sometimes I'll find different things, e.g.
It works if I truncate it to {16,15,10,8}
characters, regardless of what 20 character
password I input, but won't work if I
put in the full 20 character password it
originally accepted (even some classic
Unix can have this issue - historically
passwords were max of 8 characters, if one
input longer, they were silently truncated.
Then when the software was changed to allow
longer ... anyone who'd been inputting more
than 8 characters found their password no
longer worked ... unless they truncated their
input to 8 characters).
Likewise, try truncation, character by character ...
and I'll find, though it accepted setting a 20
character password, it now authenticates with a
3 character password - apparently having truncated
at and all characters past some certain
non-alpha-numeric character.  Often that
character is one used to delimit
SQL statements.  Gee, I wonder what
it'd do with a SQL command after such
a non-alpha-numeric character it
dropped and dropped all following from
the password data it actually saved?
<sigh>
So, yeah, many many sites - far too many,
still do quite stupid things with passwords.

Oh, and don't worry, ... it's just a government
site that processes lots of sensitive information.
8-O

> From: "Daniel Gimpelevich" <daniel at gimpelevich.san-francisco.ca.us>
> Subject: Re: [sf-lug] stupid password sites (reinventing the wheel, poorly)
> Date: Sat, 08 Oct 2016 02:25:24 -0700

> Top-posting, because you did, and it's viral:
>
> If I read your post right, you have that backwards:
> https://wiki.sonic.net/wiki/Password_Guidelines
>
> On Fri, 2016-10-07 at 23:02 -0700, Michael Paoli wrote:
>> Speaking of reinventing the wheel poorly:
>> Password: Must not be a dictionary word
>> And, the password I tried to set?:
>> l+zZu3q55`$8!{dk
>> And, you wonder why folks often end up picking poor passwords.
>> Well, when sites stubbornly and stupidly reject perfectly good
>> fine secure passwords, folks will often resort to poor passwords.
>> Okay, it's not a good password *now* that it's been publicly posted,
>> etc.  But, prior to that it was.  And I don't know what crack they're
>> smokin', but I'm sure they ain't got that in no dictionary - at least
>> certainly not before my posting it here.  Geez.  This is 2016.
>> This it the kind'a misbehavior I'd expect from a web site done in like
>> 1996 or so.  Two decades later you'd think they'd stop doing such
>> stupid stuff.  The problem has long since been solved, yet folks keep
>> screwing it up with stupid web sites that get it wrong.
>>
>>
>> > From: "Michael Paoli" <Michael.Paoli at cal.berkeley.edu>
>> > Subject: Re: [sf-lug] ... bring down systemd, Devuan?, choices,  
>> Usenet, ...
>> > Date: Fri, 07 Oct 2016 22:47:51 -0700
>>
>> > Those that are obsessed with reinventing the wheel,
>> > will generally do so ... and poorly, at that.  Repeating
>> > many mistakes that were made before, and occasionally
>> > coming up with new mistakes ... though generally not
>> > totally and fundamentally new - mostly just the same
>> > old bad goop all over again, but in slightly different
>> > form, and failing to learn from the history, and pick
>> > up problems and errors, from various problems that weren't
>> > present had they not "reinvented" whatever.





More information about the sf-lug mailing list