Date: Tue, 12 Mar 2013 08:57:54 +0400 From: Solar Designer <solar@...nwall.com> To: crypt-dev@...ts.openwall.com Subject: Re: Intentionally Increasing Collisions in Password Hashing Algorithms Matt, On Mon, Dec 31, 2012 at 10:08:28AM -0500, Matt Weir wrote: > In previous e-mails I went over how password hash collisions might > work for a very low value site. [...] I'm sorry I still don't have time to comment on your lengthy e-mails on this topic, but here's an idea, which you might or might not have had: When setting a password, you could be storing a truncated (collision prone) hash into the database as you proposed, but you may also be encrypting the full hash with a public key stored on the server. The corresponding private key would not be stored on a server. Before server compromise, the collisions are only a threat for online attacks. You need to truncate at a length that does not make these attacks too likely to succeed for too many users (remember these are low value accounts) before hitting the online password probing limits in place (there will need to be some). After temporary server compromise, the collisions also make offline attacks a lot easier. Those colliding passwords would be usable to log in. However, the full hashes may now be temporarily decrypted (on the admin's hopefully secure machine) and the truncation length increased - perhaps by the original truncation length. That is, if originally we were truncating at 20 bits, now we'll have to increase this to 40 for existing hashes, but can stay at 20 for newly set/changed passwords. Yes, a second compromise, if it occurs, will reveal some of the 40-bit hashes, which will be enough to crack mostly exact passwords (out of those for which the attacker does get a 40-bit match). Thus, those passwords will be almost as vulnerable as they're with storage of full hashes, as it relates to their possible reuse on other sites. Overall, this scheme gives some of the advantage of the original idea (for passwords set/changed at most 1 server compromise ago) while avoiding its worst drawback (inability to protect otherwise-strong passwords to this very site from offline attack after the very first compromise). Alexander
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.