[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJ9ii1FpJs5RZ7DNs67-+NugJHfcioWHYMmaJXBEt7+fvUYs8w@mail.gmail.com>
Date: Thu, 13 Dec 2012 11:03:10 -0500
From: Matt Weir <cweir@...edu>
To: crypt-dev@...ts.openwall.com
Subject: Re: Intentionally Increasing Collisions in Password
Hashing Algorithms
Anthony,
That's exactly what I'm suggesting to investigate, (and you put
much more succinctly than I could.)
Havoc,
I hadn't even considered either points #1 or #2 before you
mentioned them. As to your first point for dealing with hash
disclosures, I really like it. Ideally user accounts would be locked
and not unlock-able until the user had confirmed their authenticity
some other way, (usually through e-mail resets). For many websites
though a user might not care enough to change their password. Aka
rather than require the user to remember a new password and/or
potentially reuse a password for a more valuable site, give them the
option to continue to reuse their old password while protecting them
as much as possible.
As a somewhat related side note, the only public example/data that I
know of for the rate at which users change passwords after a
compromise is from the Webhostingtalk hacks. Originally the site was
hacked March 21st 2009 and all the password hashes were posted
publicly online. The response from the site left a bit to be desired.
They said, and I quote:
“Passwords are hashed with salt. It would be an unprecedented event to
reverse engineer our passwords. I change my password periodically
though, so maybe today is a good day for that.”
On April 7th the site was hacked again and all the passwords were once
again posted online. Comparing the two lists showed that less than 1%
of users had changed their passwords, (about 0.6%).
If anyone knows of any other examples like this I'd be very interested
in hearing about them.
Now one potential downside with your approach in #1 is if a site is
re-compromised after they start changing salts when users log in, then
the attacker could combine the two hashes plus related salts to
effectively eliminate most collisions, (aka treat both of them like
one single hash). That being said, I think the potential advantages
would outweigh the negatives caused by a site being re-compromised.
Aka I'd rather the attacker steal a throwaway password vs stealing two
different passwords for the same user. So once again that's a neat
idea you came up with.
As for point #2 I agree with you at that level of investment, tamper
proof hardware might be a better solution. Another option might be to
monitor dummy/honeypot user accounts as that wouldn't require a
separate hashlist to be maintained/protected.
As for the issue of sites adopting hash collisions for altruistic
reasons, I just don't see that happening. That's why I'm very
interested in the upgrade/deployment issues involved in this. If
password hash collisions turn out to be beneficial, ideally this would
be an option that is enabled by default in several popular
forum/webhosting software. While it could be disabled by knowledgeable
site admins, (who would probably know enough to secure their sites
reasonably well, or at least make a good effort), admins who just
accepted the default settings, (and thus probably are running less
important and more vulnerable sites), would have this applied to their
user's password hashes. I agree with you though that this is a
political question, and quite honestly we still need to figure out if
this is a good idea or not before we talk about deployment.
Matt
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
