[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
