Hacker News Reader

Comment by greypowerOz | Hacker News Reader

my non-crypto intuition on hashes is that the key idea is that there should only be one hash that matches my password (no collisions i think is the word? )

So naively i understand that a non-salted hash for "password" is a terrible idea, since two peoples hashes for "password" will be the same..

but i still struggle with the practical safety this gives in db breaches where the salt is in the breach..

Troy seems to say that this makes the cracking process slower, which think i see...

but is it fair to think that the KEY ISSUE is the uniqueness of the hashing function for any given input string?

View on HN

Rainbow tables: https://en.wikipedia.org/wiki/Rainbow_table

They are just trying to avoid a quick lookup in a pre-computed table. Adding a salt means they have to start from scratch.

Uniqueness is not really a factor, reversibility is. Given a hash will be fixed-length, and passwords can be an arbitrary length, you get a very large number of passwords mapping to each hash. But the key is to make them hard to find.

So for the server it's good to have a strong (which often means slow to compute) and non-broken scheme. Something like MD5 is just too fast to compute, if someone is targeting you in particular (and not the entire breach) you might have a bad time anyway. Some schemes have a work factor meaning the computer basically repeats calculations a lot to waste time, which a cracker would also have to do. This factor can be updated to keep up with computing power over time.

On the client the best you can do is not reuse passwords, make them long, and try not to overlap with any known wordlists (dictionaries, past breaches, etc).

Not having a salt means that hashes can be precomputed for common passwords and the exercise of cracking passwords is a simple text search in your precomputed table.

Having a salt means that the universe of password:hash correlations is different for each password entry.

It's not guaranteed to be unique.You can have multiple things that hash to the same value.

thanks, yeah that's what mean... but i see that the the core insight is that using salted hashes has an exponential decrease in the ease of finding and storing "hashed passwords" for a lookup tabke

So am i still in the right mindset to think that the "uniqueness" of every hash/ lack of collisions is still a valid area?

ie that the hash function is really unlikely to produce the same hash twice....

Reply on news.ycombinator.com