Suppose we have passwords that are statistically 7-8 characters long. Is appending a 200 character long salt less secure than a 5 character salt, because of the similar hash function inputs?
I was wondering: what if someone tries to guess the salt by brute forcing the salt with for example the password "123456", or another popular password that can be found in the system or even on a known password from the hacker's own account?
As Mike and Gumbo have mentioned in comments, a salt isn't intended to add protection to bad passwords. It's meant to keep the attackers from breaking the whole database at once. The length of the salt isn't meant to add difficulty to breaking the stored passwords. It's meant to ensure that your salt is reasonably unique compared to others on the Internet, and (if you're doing it right) no two of your users will have the same salt.
Imagine you have 20 users who all have "god" as their password. Consider the following scenarios:
Passwords are unsalted
The attacker can use a precomputed table to break one user's password in very short order. On top of that, once he has the first of the 20, he'll also have the other 19 since their hashes would be identical.
Passwords are salted. Salt used is fairly short. Same salt is used for all users.
The attacker might have to look for a bit, but could possibly come across a precomputed table made specifically for your configuration. After that point, see scenario 1.
Passwords are salted. Salt used is reasonably strong. Same salt is used for all users.
Chances are, the attacker won't find a pre-computed table for your system on the Internet. He'll have to make one of his own. This will take a bit of extra time. However, after that's done, we're back to scenario 1 again.
So, use long salts and make them unique per-user. But don't count on that to help individual users much if they're using "god" as their password.
0. Passwords are unhashed. - I know it sounds stupid, but it happens!
A too long salt will not reduce security. A too short salt will reduce security.
As the salt gets longer security will improve. At some point you will cross a boundary, where you start getting diminishing returns on increasing salt length. And eventually you will cross another boundary, where a longer salt does not add any security whatsoever.
However since a longer salt doesn't have any significant cost, there is little reason to stop increasing the length until you reach the second boundary. Even if you were to increase the salt length beyond that, the only drawback is minor extra cost in terms of storage and processing time.
Sadly salts are more often generated with a length below the lower of the two thresholds.
So what are the two thresholds?
The lower threshold is determined by the number of users and the purpose of the salt, which is to be different for every password ever chosen by any user. If we take some conservative estimates, the number of users worldwide is less than 10^10, and each user has passwords for less than 10^2 systems and over their life time changes this password less than 10^3 times. That means in total there will be less than 10^15 passwords. Given this, one might erroneously conclude that 50 bits of entropy in the salt is enough to guarantee that there will never be two salts repeating, but due to the birthday paradox we have to double that number.
So once the salt grows longer than 100 bits, we start seeing diminishing returns in terms of added security. The 100 bits threshold involved a lot of guessing. The next threshold involves much less guessing. More than 100 bits of entropy in the salt still improves the security, just not by much.
Once the salt grows to be longer than the output of the underlying hash function there is however no added security from making it any longer. What the threshold is depends on the hash function, these range from 128 to 512 bits for typical hashes.
Remember that salts are usually generated with 6 bits of entropy per character, so you would need 86 characters of salt to reach the 512 bits of entropy.
The only property of a salt that is important from a security perspective is that it is globally unique. The length may impact how unique the salt can be, but is irrelevant from any other perspective. Assuming that it has a positive or negative effect on anything is to ask the salt to perform a function that it was never intended to serve.
So, a salt should be long enough to reasonably assure uniqueness, and that is all. Assuming your salt has good uniqueness, any longer will not impact security positively or negatively, but will most assuredly waste storage space.
Others have commented on the proper use of salts and passwords but maybe it's useful to add a word on hash functions because your question seem to suggest a somewhat incorrect intuition of the way they work.
By design, a good cryptographic hash function should not let you guess how similar the inputs were based on the hashed values themselves. Otherwise, it could be inverted by gradually reducing this distance which would be much less costly than pure brute-force guessing. So hash(salt1 + “12345”) should not be more similar to hash(salt1 + “67890”) or to hash (“12345”) than to hash(salt2 + “67890”).
The whole point of the salt is making sure that the inputs (and hence the hash) are not identical even if two accounts happen to use the same password but similarity should not be an issue.
The length of a salt follows the law of diminishing returns.
At no point does a salt become less secure by being longer,
but it does stop getting meaningfully more secure relatively quickly.
You never "crack" a salt - what you are cracking is the hashed password, to which the salt is appended. The salt just addresses the threat of rainbow tables - the ability to find pre-computed tables of hashes allowing you to skip the laborious process of brute-forcing.
For this purpose, all you need are salts long enough that nobody will already have created comprehensive rainbow tables for all such possible salts yet. And due to the cost of creating a rainbow table and the exponential growth in the number of salts you'd have to calculate as you increase the maximum salt length, this is not a very difficult requirement: only a few characters of salt will already be highly likely to ensure that nobody has calculated comprehensive rainbow tables on salts of your format.
To pick a random value out of nowhere, salts of, say, 16 hex characters or more are going to be quite good, assuming your method for picking them randomly has no exploitable flaws.
Beyond this, the increase in security becomes more and more negligible.
