If you have a long enough and random enough password, you're probably good. The trouble with short passwords is that there just aren't that many of them. An attacker can just compute the hash of all of them.
As long as the salt is secret from the attackers (which is not a given, of course), the length of the passwords shouldn't matter all too much; the input to the hash (i.e. password + hash) would still have enough entropy to not be brute-force-able.
If you have the hashed password, in most systems you have the salt. Salt+hash is for preventing the attackers from getting to try all your passwords in parallel.
Maybe this is what you're saying, I'm not sure - my understanding was that the salt prevents reused passwords from resulting in the same hash. So, if I use 'password' and you use 'password' the salt+hash will be different. That way attackers can't just hash all the common passwords once and immediately associate them with different accounts.
Yeah, exactly. Commonly, the salts are stored right next to the hashes in the DB, because they serve their purpose even if the attacker knows what the salts are. By using a different salt for every password, the attacker needs execute a full "guess, hash, compare, repeat" attack on each user, as opposed to "guess, hash, compare against all user passwords, repeat" on the entire database.
You can also have a system salt(s) that are not stored with the database, so that if someone accesses the database they have to guess password and two salts, one of which they hopefully do not have via the same penetration.