[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <033801ce1ef0$ae26dd50$0a7497f0$@edu>
Date: Tue, 12 Mar 2013 03:10:28 -0400
From: "Matt Weir" <cweir@...edu>
To: <crypt-dev@...ts.openwall.com>
Subject: RE: Intentionally Increasing Collisions in Password Hashing Algorithms
Hey Solar, thanks for the reply and the idea!
>> I'm sorry I still don't have time to comment on your lengthy e-mails on
this topic
Don't worry about it. I'll be the first to admit I need to learn to be more
succinct.
>> 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.
That's a cool idea, but unfortunately I don't think it would work in
practice. The problem is the public key, (yes the public key), is stored on
the server. While normally the public key doesn't need to be secret, (hence
the whole public part), possession of it would allow an attacker to treat
the resulting full encrypted password as a hash. Aka, an attacker can take a
guess, encrypt it using the public key, and then compare it to the encrypted
password. While the asymmetric crypto used might be slower than the actual
hash function, an attacker would only have to verify collisions.
Now I don't have a good solution for remediating a breach when truncated
hashes are used so I appreciate all the suggestions I can get. Right now
though I think that risk will simply have to be accepted, so strategies to
deal with breaches fall more into when to use truncated hashes where the
risk is acceptable. Aka don't use them for admin accounts, or where
sensitive data like credit card info is stored. Other strategies fall under
what is "best practices" for normal breaches, such as monitoring for
suspicious activity, (such as logging in from new IP addresses), resetting
passwords via e-mail, or requiring captchas until the user changes their
password.
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.
