[Chicago-talk] Password strength

Fri Aug 7 11:00:24 PDT 2015

> I cannot discern what the problem with storing old MD5 hashes of the
password would be from it

> 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

An attacker would not be looking for similarities in the hashes themselves,
they would be looking for similarities in cracked passwords.  Cracking an
MD5 hash is somewhat trivial (particularly if you're talking about unsalted
data going into it), if an attacker has access to unsalted MD5's and
distills that down to a list of passwords containing things like
"applejack4", they are going to have a reasonable degree of success trying
current passwords similar to this (e.g. "applejack5", etc.).

Particularly for systems that force regular password changes, users often
skirt this requirement by just incrementing a number at the end (or some
other similar common change).

Furthermore, once a known password scheme for a set of users has been
compromised, an attacker would also have a reasonable level of success
applying these known passwords (with small variations) to a wide variety of
other accounts in other systems tied to that same email address.

I'd also flip the question around on you:  What on earth would you have to
gain by storing old passwords (or *any* passwords) with an MD5 hash?  The
savings on a few bytes of data simply isn't worth the risk you introduce.

In short:  Don't use MD5 (at least not for anything even remotely related
to sensitive data).

-Chris

On Fri, Aug 7, 2015 at 12:35 PM, Joel Limardo <joel.limardo at forwardphase.com
> wrote:

> "...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
>>
>
>
>
> _______________________________________________
> 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/1c59e85c/attachment-0001.html>