[Chicago-talk] Password strength

[Joel Limardo]

"...I wouldn't personally suggest doing this (and if you are going to do
it, I certainly wouldn't store them as MD5 hashes)...."

I read the suggested article on stackexchange and I cannot discern what the
problem with storing old MD5 hashes of the password would be from it.  One
reply seemed to indicate that successive, nearly similar versions of a
hashed password could somehow be used to discern the password:

"...A user uses a relatively weak password, realizes this and updates the
password to a better password...superawesome -> !sup3eraw3s0m3!"

But the hashes of even those two examples are so markedly different I
cannot imagine what process would be used to identify anything similar
between them:

$ perl -MDigest::MD5 -e 'print Digest::MD5::md5_hex(q|superawesome|);'
b088b8dd3440c243eac53b2b23003c60

$ perl -MDigest::MD5 -e 'print Digest::MD5::md5_hex(q|!sup3eraw3s0m3!|);'
f1e8301312feacb45b752a6ce77eb880

MD5 hash 'reversal' appears to be done using some kind of dictionary file
(see http://www.perlmonks.org/?node_id=727370) which is defeated by using
the *combination* of numbers and characters as I recommended.

The biggest issue appears to be with asking a user to recreate a password
after some time period. The complaint is that it forces users to pick
passwords that are weaker. Responders agreed that forcing the password to
be a particular length (much like, "enter a password of an appropriate
length") is a solution here.

So I'm confused about what the issue would be with using MD5s if my
recommendations are taken together. Any insight?

On Fri, Aug 7, 2015 at 11:07 AM, Chris Hamilton <cjhamil at gmail.com> wrote:

> > Disallow reuse of passwords (store MD5 hashes somewhere)
>
> I wouldn't personally suggest doing this (and if you are going to do it, I
> certainly wouldn't store them as MD5 hashes).
>
> Presumably you're generating a new salt and strongly hashing the password
> each time it's changed, as such your easiest choice is storing a history of
> prior salt/hash combinations and comparing against these.  Still, I'm not
> sure I'd recommend spending too much time caring about password reuse,
> because unless you're going to disallow password reuse for all time, you
> aren't actually preventing someone from reusing a password anyway (they
> just need to go through N+1 quick password change iterations to get back to
> where they started).
>
> Some related reading:
>
>
> http://security.stackexchange.com/questions/85074/is-it-safe-to-store-a-password-hash-history-for-preventing-user-to-keep-same-pas
>
> -Chris
>
> On Fri, Aug 7, 2015 at 10:53 AM, Joel Limardo <
> joel.limardo at forwardphase.com> wrote:
>
>> If I'm not mistaken a strength meter tells the user 'hey..your password
>> is weak' which doesn't *force* them to change the password *nor* does it
>> tell them how to make a better one. As a rule of thumb, once you find
>> yourself acting on more than one assumption it is a good sign that you have
>> too many variables on hand to make a workable design.
>>
>> I would instead a) force the user to enter a password of an appropriate
>> length with certain characters like numbers and symbols b) periodically ask
>> users to update their password (every 3 months, etc.) c) Disallow reuse of
>> passwords (store MD5 hashes somewhere) d) check IP addresses to identify
>> potential unauthorized access.
>>
>>
>> On Fri, Aug 7, 2015 at 9:35 AM, <richard at rushlogistics.com> wrote:
>>
>>> I am using perl dancer to create a new user login page. I was surfing
>>> arround to try to find how to create a password strength meter when I found
>>> this http://www.perlmonks.org/?node_id=948997 which has me
>>> second-guessing as to whether having one is even a good idea. Can anyone
>>> lend some insight in this matter and perhaps where to go get a good one if
>>> you believe they are a good idea?
>>>
>>> Thanks,
>>>
>>> Richard
>>> _______________________________________________
>>> Chicago-talk mailing list
>>> Chicago-talk at pm.org
>>> http://mail.pm.org/mailman/listinfo/chicago-talk
>>>
>>
>>
>>
>> _______________________________________________
>> Chicago-talk mailing list
>> Chicago-talk at pm.org
>> http://mail.pm.org/mailman/listinfo/chicago-talk
>>
>
>
> _______________________________________________
> Chicago-talk mailing list
> Chicago-talk at pm.org
> http://mail.pm.org/mailman/listinfo/chicago-talk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/chicago-talk/attachments/20150807/0e96148a/attachment-0001.html>