A lot of developers when ran to “salt” asks about the usage of it and unfortunately many are not convinced to use it because they do not understand the actual usage of salts. In one sentence salts are to defend against one special type of dictionary attacks by increasing the size of dictionary. The reason is that salts are added to the passwords and then the hashed result is saved so the dictionary needs to contain much more entries to crack salt + password hashes. Let me clarify the concept by comparing three types of password storing.
In case of saving password without hashes (in plain texts) you have no guards if someone accesses your database because they see the passwords of your users. In case of saving hash of 10-letter passwords without salt you are in danger of dictionary attacks. You may argue that a 10 letter password containing both digits and alphabets need 36^10 comparisons or almost 10^16 comparisons. Well the bad news is that using Rainbow tables, number of comparisons reduces significantly and in some cases in seconds the password is cracked! Salt makes this type of attack much harder by increasing the size of hash. For example a fifty-character salt increases comparisons to 36^60! This number is almost (10^16)^5 bigger than the hashed passwords without salt!
One misconception is that developers think salt protects them from Man-In-The-Middle attacks; well none of above methods protects you from a Man-In-The-Middle. In such attack, the attacker sniffs your network’s traffics and steals the communicated password. To protect such attack you should acquire a method of encryption for example using SSL. Salts and hashed passwords do not protect you from Man-In-The-Middle attacks; they protect you when your stored passwords are disclosed.