I thought the reason to use variable, random strings as salts is to force the attacker to look up every salt before using his rainbow table on the hash. This takes a long time.
But most developers seem to use fixed sizes for their salts. If you look up the size of one salt, which you know because most passwords are stored alongside with the salt, couldn't you just cut the salt length off every password digest and then use your rainbow table?
I don't see how this would be too much of an effort and it makes me question why I should even use a variable salt. Because the only information the attacker needs is the size of one salt and then he doesn't have to look up anymore salts. Wouldn't a randomized size be much more secure?
The variability and randomization really seems like a 'security through obscurity' thing to me, because it's so easy to workaround if you know the method and the only reason to implement it is to cause some moments of confusion. Or am I wrong?
Salts can be of any length. The only requirement of a good salt is it is 'sufficiently unique' as it is this property that makes rainbow table attack unfeasible against salts: it would take more time to generate the rainbow table, that would only work for a given salt, than to just attempt a brute-force attack1.
A public salt makes it more time-consuming to crack a list of passwords. However, it does not make dictionary attacks harder when cracking a single password. - Salt (cryptography).
An easy way to generate a good salt is then to generate a large (say, 128 random bits) value from a cryptographic random number generator. This will trivially ensure salts will be of the same length - but there is an insane amount of unique values that can be represented by 128 bits.
Since the hash is generated using the original 'long' salt, using a trimmed salt later would just yield an invalid hash when specifying the original password - it doesn't make it any easier to find a hash collision. (Choosing a 'slow' hash like bcrypt is another requirement for a good hashed password design.)
If an attacker was able to trick a system to use a small range of salt values (or even a fixed salt value) then the salts lose the property of 'sufficiently unique'.
1 Sadly, many people choose poor passwords - mainly passwords that are too short, based on common words / sequences, or shared between sites. While a slow hash will help a good bit, and the salt prevents application of rainbow tables, given a large enough pool of accounts (and less time then may be expected) a brute-force is still likely to recover some passwords.