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.