Fast cryptographic hashes like SHA-1/2 are heavily discouraged for password storage (even with a salt). As they are very easy to implement in parallel.
Yes salting prevents as effective brute forcing. Yet modern computing 8 char passwords + salt can be exhausted within 24-48 hours (on a <$20k GPU cluster) if you using SHA-1/2 + salt.
bcrypt/scrypt/PBKDF2 are much harder to brute force (by design) and circumvent this weakness.
Salts defend against one idiosyncratic lookup-table attack that was briefly popular in the early 2000s because of a widely-deployed password hash function that, unlike every password hash since the mid-1970s, didn't randomize. This is the attack to which "rainbow tables" are applied.
If you're considering rainbow tables as part of your threat model, you're already so boned that you should give up and just use a real password hash. If you're not considering rainbow tables, you don't have to consider salts.
The only good thing about "strong salts" is that they function as a kind of shibboleth so you can tell if people understand what problems they're contending with when storing passwords.
The original Unix crypt function was, IIRC, salted.
To head off an unproductive discussion, I'll just repeat:
* salts do zero to mitigate brute-force attacks
* even trivial salt schemes break table-based attacks
* the overwhelming majority of passwords are cracked through brute-force, which is attack vector that real-world password hashes need to be evaluated on.
The job of a password hash is to strengthen weak secrets in compromised databases. Your suggestion defines the problem away: "never lose the whole database", it suggests, "and you don't have a problem".
Yes salting prevents as effective brute forcing. Yet modern computing 8 char passwords + salt can be exhausted within 24-48 hours (on a <$20k GPU cluster) if you using SHA-1/2 + salt.
bcrypt/scrypt/PBKDF2 are much harder to brute force (by design) and circumvent this weakness.