[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <50C96D9A.10005@defuse.ca>
Date: Wed, 12 Dec 2012 22:54:34 -0700
From: havoc <havoc@...use.ca>
To: crypt-dev@...ts.openwall.com
Subject: Re: Intentionally Increasing Collisions in Password Hashing
Algorithms
On 12/12/2012 04:03 PM, Matt Weir wrote:
> So this is a continuation of a rather long Twitter thread between
> Solar, @DefuseSec and me, (apparently Twitter is not IRC), talking
> about increasing collisions in certain password hashing algorithms as
> a defensive measure.
[snip]
>
> There are several other advantages to increasing collisions by
> truncating existing hashes. First...
Hopefully without getting too far off topic, here are a few other
advantages to increasing collisions:
1. Assuming it is hard to find a user's *real* password (not just a
collision) from the hash, then if the hash file is leaked, you can be
less strict about making users to change their password. You just have
to change the salt next time they log in. I doubt most users actually
make significant changes to their passwords, since when they are forced
to enter the new one, they're probably in "i just want to use it, let me
in!!"-mode and won't take the time to memorize a new one. Of course
users should be told to change their password, but this provides some
level of protection when they make a very predictable change.
2. You can setup a honeypot sort of thing to detect hash file leaks: At
random, send full-strength hashes of users' passwords to a separate
server that is only physically capable of receiving data. This server
can monitor the "collision rate" (the number of login attempts that are
succeeding due to incorrect passwords colliding with the weak hash), and
if it goes above what would be expected under normal circumstances, it's
a good sign that someone is logging in with collisions they found by
running offline attacks on the hash file.
Although if you can afford a setup like that, then you can probably
afford tamper-proof hardware with embedded keys to do the hashing.
>
> So this leaves a lot of interesting questions. For example where
> should this be used and on what accounts? Aka you might not want to
> use this on webmaster accounts while using it for normal users. Also
> you may not want to use it for accounts that contain sensitive info as
> the assumption that if an attacker has the hash then they have access
> to the user’s account might not hold true. Then there’s the basic
> question of how likely should collisions be? Plus it's still left to
> be determined if the advantages of this approach outweigh all the
> negatives even for unimportant accounts.
>
Another question is: If we can show that increasing collisions does have
some benefits, it's almost certainly going to benefit other websites the
most. If that's the case, would it even be adopted? Since implementing
it would be admitting that your website is low value, and evil
corporation X might not be willing to sacrifice any of their security,
even if it does increase their users' security with respect to competing
corporation Y.
This is a political question, though, and I don't think it should stop
us from exploring the possibilities.
I don't think we should be too quick to say we should only increase
collisions on low-value sites. If it turns out that there is almost
never a scenario when an attacker can read the hash list without being
able to write to it, or if the amount of accounts an attacker can get
into by finding collisions is pretty much the same as the amount they
could normally get into by going after low-hanging-fruit passwords, then
it makes sense to increase collisions on high-value sites too.
--
Havoc
https://defuse.ca/
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.
