Hacker News new | comments | show | ask | jobs | submit login

isn't slow better in this case? I mean if it's fast to generate, it's fast to crack, right?

> isn't slow better in this case?

No, guy's looking for a hash table hash, not a cryptographic one. For a hash table you're looking for low collisions and high throughput (so your hash table is fast) first and foremost.

Even for cryptographic hashes, fast is what you want most of the time. Look at it this way: when you connect to a web site via SSL, all the data you send will be hashed for authentication. Do you really want this to be slow?

Cryptographic hashes should be as fast as possible while not sacrificing collision resistance. Hashtable hashes should be as collision resistant as possible while not sacrificing speed.

Sort of anyway.

For cryptographic purposes you usually want fast digests and slow key derivation functions.

The person specifically requested an algorithm for a hash table. Nobody is going to attempt to crack that

nobody? This exact problem was a massive issue within the year.


Using a slower hash would make the issue worse (linearly): the collisions would still be there, but now each insertion would take even more time due to the extra computational cost of the hash.


EDIT: parent basically said "use a cryptographic hash".

You need some kind of random salt, too - it's not that hard to find a decent number of near-collisions even in cryptographic hashes. (E.g. if your hash table doubles in size whenever two keys end up in the same bucket, an attacker needs to spend O(2^n) operations to find two keys that agree in the first n bits, which will make you do O(2^n) operations and use O(2^n) memory.)

> No, using a slower cryptographic hash would produce better distribution

That absolutely isn't an intrinsic property of cryptographic hashes.

Using a faster cryptographic hash would be better.

Not if you're not looking for it to be hard to crack. Suppose you're generating quick checksums, using a hashtable, indexing non-malicious data, etc. In those cases you want a very fast hash function, and you're not worried about folks being able to find collisions for existing hashes, or create multiple values with the same hash.

There are times you want something that won't be a cracking attack. E.g. to randomly (but consistantly) partition data (i.e. a hash table).

Given Moore's law and the prevalence of botnets and cloud computing - hash speed really isn't a very strong means of defence against cracking...

Also see: http://cyberarms.wordpress.com/2010/10/21/cracking-14-charac...

Uh? Hash speed is pretty much the only means of defense against brute-force cracking (assuming the hash function isn't broken and the attacker has no other vector available).

(low) hash speed is the whole point of PBKDF2, bcrypt or scrypt.

Can we stop calling them hashes? They're key derivation functions. I know it's a long, awkward term, but a lot of people in this thread are confusing the technical requirements for cryptographic hashes and KDFs, so I think that being precise about this is warranted.

But talking about salt in our hash sounds delicious.

Talking about stretching our hash, though, sounds like some strange tasting taffy...

You'll find that adding a long salt, unique to each password, is a far more effective protector against brute force than "hash speed".

See this: http://net.tutsplus.com/tutorials/php/understanding-hash-fun... and: http://stackoverflow.com/questions/1191112/password-hashing-...

to learn more about preventing brute-force attacks

> You'll find that adding a long salt, unique to each password, is a far more effective protector against brute force than "hash speed".

No, I'll find that you've apparently stopped your education at hashing 101 and hashing speed is covered in hashing 102.

1. It's not an either-or situation, all three hashes I mentioned not only specifically include salts in their hashing interface but go as far as mandating a salt for brypt and scrypt (I don't believe PBKDF2 mandates one though it surely is recommended)

2. Salts don't protect much against brute-force attacks, their primary role is to protect against rainbow tables (dictionary attacks) in case the hashed data is leaked. They do add cost to brute-forcing a series of passwords (if salts are unique), but that cost is low compared to

3. Hash speed mitigates brute-forcing from both inside (leaked data) and outside (provide built-in rate-limiting, of course additional rate-limiting is still a good idea). Increasing the raw cost of computing the hash by multiple orders of magnitude and adding data dependencies within the hash (to prevent trivial parallelization) are very much vital against brute-force attacks.

4. You might have wanted to read your own bloody links, the first one specifically mentions hash speed to mitigate brute force attacks, and mentions salts only against rainbow tables; responses to the second one specifically note that salt mitigate rainbow table attacks but do not significantly mitigate brute force attacks especially on weak passwords.

If you did your research, you'd know that salts are insufficient protection. Heck, read your own link, the first link has as #7 that you need to use a slow hash function. Or you can just read http://codahale.com/how-to-safely-store-a-password/ which lays it out in black and white.

You should be glad. You learned something important today.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact