Re: [Savannah-users] password must be more complicated

[Bob Proulx]

>       $ echo Iephoo3i | pwqcheck -1 match=0 max=256 min=24,24,11,8,7
> It is 8 characters long but not 8 *unique* characters -- o is repeated,
> there are no repeated chars in ox8iChae.

Of course that shouldn't matter.  Randomness will have clusters.

One of the old experiments is to have people say heads and tails in
what they think are random and have another flip a fair coin.  Record
both.  Look at them and it is usually obvious which one is truly
random and which are the non-random humans.  Randomness will have
clusters of repeats and humans tend to avoid those.

> Could that be the reason?  Just a wild guess.

In the words of Zathras, "Cannot say.  Saying I would know.  Do not
know, so can not say."

> (I think it is absurd that this password is rejected, BTW.)

Agreed.

> It is one of the problems, for sure.  Users put together 3 different
> classes in their 8 chars (already a big pain), it fails, and since the
> feedback as to why it fails is not specific, they just iterate randomly
> and find one that works.  Very frustrating.  I've been frustrated by it
> myself.

Yes.  Let's fix this then.

> Is there a way to get pwqcheck to report more specifically why a pw is
> bad?

It is actually telling us what it thinks is wrong.  But as far as I
can tell that is just incorrect.  So we toss it out thinking that it
isn't really telling us the right thing.  Because it isn't.

Having pwqcheck tell us the right thing is basically fixing pwqcheck.
Because currently it says things that defy reason.

>     Taking a completely different approach...  Does anyone have a good
>     method of checking and ensuring password strength?  The goal isn't to
>     use pwqcheck but to try to avoid the too-weak password problem.
> 
> At one site I administered, I had a pwchange script which would try to
> crack the proposed password for a few seconds.  (And for longer
> overnight.)  That caught a lot of things -- the things which crackers
> would be most likely to find -- without being much of a hassle.

I like this idea.  It seems a good way to test it against realistic
attacks.  But I could see that being slow too.

> Nevertheless, I think our pw requirements are too strong.  In the sense
> that sv makes requirements that no one else does.

I have had some sites require some pretty strange things.  I would
like to give them credit that they do that just so that passwords
can't be reused.  But I know it that isn't it.

> Furthermore, getting in to some sv user's web account is really not
> very interesting to crackers -- the worst they could do is screw up
> the stuff for that user's projects.

Exactly.  The risk isn't as high as the bar that has been set to
protect it.  I think it needs to be sized approrpiately for the risk.
The risk here seems low so I think we need to make the entry match it
appropriately.

> My experience is that cracks are directed at gaining shell/root
> access.

Or any possible way to send email.  Spam generation is prized.

> Anyway ... can you make a proposal for the pwqcheck args to reduce
> the pain, Bob?  I am not sure where we stand.

First I would definitely propose we set match=0 to try to avoid the
false positives.  That would reduce the rejection rate from 13% to
7%.  That seems reasonable and would improve things.

But I would also ask if we need this at all.  Or perhaps implement a
simpler check.  I know that Ineiev thought it was useful to keep the
check.  I think I mildly disagree.  I think it is useful to use
pwqcheck and if it passes that then stop there.  But if it fails
pwqcheck I would like to look to see if it is a false positive.  Look
to see if it has a reasonable amount of character classes and if so
then mark it okay.

Basically do what pwqcheck says that it is doing but isn't.  Because
the risk of getting this wrong isn't that much of a problem.  I will
look at the php and fix it to do that.

Bob