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.