The salt is typically assumed to not be secret. With modern hardware recalculating the hash is not hard for "fast" hashes, regardless of salting. That's why choosing a slow hash is more important for this vector of attack than anything else.
Of course salting is better than no salting, but its orders of magnitude less important than choosing a good hashing mechanism. Luckily, the good hashing mechanisms do the salting for you so fixating on salting really just serves as a proxy for letting us know that you don't understand the attack vector.
Whether the salt is secret or not doesn't matter. If it's known that I salt passwords in the USERS database with the `uname` field, hashes for "workloginpa$$word" and "kasey_junkpa$$word" will look different, even though our passwords are the same. There's no easy way to compare passwords when they're salted, and that's the point to understand.
Yes, having a good hash in the first place is more important, but salting is right up there.
No, it's not, because choosing a proper KDF will make your passwords take years to crack, while choosing a standard digest with a salt will turn the time from fractions of a second to days.
The only thing that matters is whether or not your password database ends up on a message board somewhere, not about how you feel about hashing.
A proper KDF is more important if you are trying to break a specific user's password. It will simply take too long to try any reasonable number of attempts. However, in the event that you have a large database leak individual salts become just as important. When looking thousands of users, unsalted hashes allow attackers to start with the most common passwords used and compare them to the entire leaked database in one try.
this whole discussion is a red herring. Of course all current KDFs include salting as a form of key stretching. That's because no one designing them is writing off rainbow table attacks.
Since DDG does it quick, I'll use MD5 as an example, but don't ever use MD5 as your hash!
An attacker already knows a user's plaintext password is "pass123" and no salting has occurred. He can search for "32250170a0dca92d53ec9624f336ca24" in the database and find 5 other users that have the same hash. He now knows that those 5 people have the same password.
I think you're severely underestimating the importance of salting. I agree that choosing the "correct" hashing algorithm is more important than salting, but not by magnitudes.
Even if you're using a "hard" hashing algorithm, you're significantly reducing the amount of computations an attacker would have to go through by forgoing salts. Especially considering that salting has very, very little overhead.
I was skipping some complexity. Something like b/scrypt are more than just hashing. They are key derivation functions, which look similar to hash functions on their inputs.
bcrypt for instance generates a random salt on the input and stores it in the output.
A lot of password hashing APIs have two calls - one where you provide the password (and possibly work factor) and it returns a hash that includes a randomly generated salt, and another where you pass in the hash (which includes the salt and work factor if any) and the password which returns true/false.
Of course salting is better than no salting, but its orders of magnitude less important than choosing a good hashing mechanism. Luckily, the good hashing mechanisms do the salting for you so fixating on salting really just serves as a proxy for letting us know that you don't understand the attack vector.