On Nov 27, 2010, at 9:01 PM, Tom X. Tobin wrote:
> But how far are you willing to go in your assumption of the worst-case
> computational ability of your attacker? Would tuning the hash to
> (say) a 10ms delay for your web server's modest hardware translate
> into a significant delay for an attacker with far more resources?
> (This isn't a rhetorical question; I honestly don't know.)
Let's do the math. The space of eight alphanumeric character passwords is
2.8e12. Even assuming you can cut two orders of magnitude off of that with
good assumptions about the kind of passwords that people are picking, this
means that the attacker has to run about 28 billion times more computations
that you do. At 10ms per password, it would take them about 447.8 years to
crack a single password, assuming hardware of equivalent speed.
> It does in fact slow down brute force attacks against multiple
> encrypted passwords; each password with a different salt is within an
> entirely different space that needs to be brute forced separately from
> the other passwords.
Remember how a brute force attack works. Given a hash x, the attacker does:
hash('00000000' + salt) = x? No, then,
hash('00000001' + salt) = x? No, then,
...
The only benefit of the salt here is that it makes the string to be hashed a
bit longer, but the benefit is linear, not exponential.
A dictionary attack works by consulting a precomputed set of passwords and
their hashes, (pwd, hash(pwd)). The attacker then runs down the dictionary,
comparing hashes; if they get a hit, they know the password. The salt defeats
this by making the pwd -> hash(pwd) mapping incorrect.
--
-- Christophe Pettus
x...@thebuild.com
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
