[by]

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.

[Xk]

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.

[by]

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.

[Xk]

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.

[ZoFreX]

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