Hacker News Reader

Comment by streety | Hacker News Reader

Does anyone have more information on the following:

"Second, the salts are only 12 bits. A proper implementation would use salts twice as large as the logarithm of the number of passwords which could ever be stored, forcing the attacker to break accounts one-by-one (64 bits would be a reasonable size to support the entire population of the Earth)."

I haven't come across a formal rule for salt length before and a search for more information didn't turn up much more than the rules of thumb I've seen previously.

View on HN

It's called the Birthday Paradox

https://secure.wikimedia.org/wikipedia/en/wiki/Birthday_para...

the rule of thumb to remember is that there is a 50% chance of a collision when the sample size reaches half the bits of the total available.

Would you really care about a single hash collision in a database of 500,000 users?

It is a salt collision not a hash collision. No, clearly one would not matter, hence staying below that would be entirely safe against a salt collision inside your database.

But if it was feasible to store 10^32 rainbow tables you should make it longer. Ah, it should probably be longer. I think 128 bit salts would be more sensible.

It wasn't the 7-bit salts that let the crackers get access to the passwords. It was DES crypt that did. They could have used 1024 bit salts and the passwords would have been cracked just as quickly.

I just ran a quick shell script over the database file. There are only 3329 password collisions. Of 700,000+. Sure, a bigger salt could have reduced that. But was that in any way the cause of the problem? No.

You talk about password collisions. I am only considering salt collisions.

Their system had many holes, one of which was the salt length. I did not mean that the salt length was the largest hole, nor that it was the one that was exploited. Just that it is a hole which could have been exploited if the others were absent.

The salt's only purpose is to prevent a password hash result being used more than once. The normal attack is to pre-compute and store a table of passwords and hash results by running lots of common passwords through the algorithm in advance. The salt needs to be large enough to prevent anybody storing a pre-computed table which has a chance of matching a result in your database. The salt also needs to be large enough that your own salts do not collide because this would reduce the work needed to crack the ones with salt collisions.

Then we agree.

Had other holes not been there, the fact that sV39Fw5at18zo occurs seven times probably indicates it is a common password. I would even guess it was '123456', or one of the other top four passwords.

In reality though, seven a seven bit salt serves its purpose to stop rainbow tables.

Thank you to both of you for showing where I was going wrong :)

I had heard of the Birthday paradox previously but didn't make the connection. Thanks for the reply.

I can't explain why double the logarithm of the number of passwords stored would be the target. But it does make sense to have at least log_2(n) salts for n passwords. That would guarantee each password, even if they were all identical, would have a unique salt making every password hash differently (at least theoretically).

Now perhaps you would double that as a just-in-case scenario or because there is some fundamental property of every (existing or future) hash algorithm that causes a collision half the time (i.e. both salt 10001 and salt 10000 generate the same hash value).

Can someone explain to me how they salted the password? From the db dump, I only saw one encrypted string. In a regular salt/hash situation, you have two encrypted strings.

My understanding was that the first two characters of the hash were the salt.

Also, encryption implies decryption which isn't possible here, apart from brute forcing. What's being done here, albeit badly, is hashing.</pedantry>

Reply on news.ycombinator.com