What effect does a salt have on attacks against hashes's fundamental properties?

Question

I am interested in analyzing how adding a salt to our hashed passwords affects the three types of attacks we can use. The three types of attacks against hashes are as follows:

1. We have the hashed output and we are looking for a matching input (pre-image).

2. We have an input (and implicitly the output) and we want to find another matching input (second pre-image).

3. We have the input and we want to find ANY output (collision).

My thought is that the addition of a salt to our output would only affect our ability to perform attack 1, because we are reliant upon the output to find a matching input. With the salt, our chances of finding a matching input becomes almost impossible because we have to check each output with every possible salt. Essentially, attack 1 is what's known as using a rainbow table.

Answer 1

I'm no security expert but I'll take a stab at this since it hasn't been answered.

Also, I'm answering as if you're asking about a Rainbow table or Dictionary attack for preimage and second-premiage attacks. Preimage being the rainbow table attack and second-preimage relating to getting similar encrypted values (cipher text) from the same password.

If you actually mean preimage and second-preimage, these attacks have nothing to do with password protection and more to do with the hashing algorithm's robustness.

Basic Salting Info

In the most basic sense, salting increases the amount of time and effort needed to crack passwords.

Salts are:

1. Unique
2. Random (GUIDs are not necessarily random. Look up CSPRNG)
3. Public (at least, it doesn't need to be a secret)

Also, make your salts robust. This doesn't mean that the password should be weak. The password itself should also be robust.

How Salting Effects Hacks

Unique salts ensure the same password will be hashed to a different cipher text.

Attack 1: Salting will increase the time needed to find other user's passwords. Because, the attacker would need to create a Rainbow Table for every salt used because salts change the output in unpredictable ways. Cracking the hash for one user wouldn't be much harder but cracking the hash for all users would be exponentially harder (I'm not sure if that's literally exponentially harder or if it just seems that way).

Attack 2: If the salts are unique then there is no matching input (idealistically. I know there's collisions). So, if you know the plain text (and salt) for one user, then that doesn't mean you'll know the cipher text for all other users with that password.

Side Note: I suppose if you had the whole database and knew every salt that was used then you could hash the known password against all the known salts and compare all of those hashes to all the values in the database. However, this is still a win for salting because that takes more time then being able to query the database with one value. Also, I think key stretching can be used to increase the amount of time needed to hash while increasing the entropy of the algorithm. All of these little things make it that much more impractical to try and decrypt large databases.

Attack 3: I don't think you need to worry about collision attacks. In a collision attack, the attacker is in control of the input. An example, the attacker presents Document 1 to Person A to sign. Person A signs it. Then the attacker puts Person A's signature on Document 2 and gives it to Person B. I think this mostly has to do with TLS (SSL) security. Salting has no explicit effect on a collision attack.

Conclusion

Salting will make Attack 1 and Attack 2 more difficult to complete by increasing the amount of time and/or resources needed to execute the attack. This is assuming the attacker is hacking to get information for many users as oppose to just one.

Don't forget, strong salts should be used in conjunction with strong passwords.