What I do not understand is what hinders an automated function to chose a username and just make a lot of login attempts on - for example - a web site, with different password each time. To me it would seem that the salt has no function in that scenario?
Correct. Hashing and salting do not prevent against brute-force login attempts. (For that, you want to limit the number of login attempts per unit of time, or to ban after X-failed attempts).
Hashing and salting are used to prevent a stolen password list being cracked (or, to increase the amount of time needed to crack said list).
When storing passwords, you have 3 options: plain text, hashed, or hashed+salted. If I steal your password list:
- Plain text: I now have the login details for all your users. I can impersonate them. (That's bad).
- Hashed: I can use a rainbow table to determine the password from the hash reasonably quickly. (That's also bad).
- Hashed + salted: Now the rainbow tables don't work. I have to spend considerably more time cracking each password. It's still possible, but it is a lot harder (and, unless you're actually important, I'm probably not going to bother). Note that this also gives you time to notice the security breech and inform your customers their passwords were stolen, and ask them to change it (so even when I eventually crack the hashed+salted list, I can't use it).
So: hashing + salting is used to prevent (or slow) attempts to crack a password from a stolen hash using brute force methods.