Salting has zero effect on the targeted cracking of a single password. Salting protects against rainbow tables - sets of pre-calculated hashes plain-text to passwords. These are dangerous because an attacker has a large amount of time to pre-calculate hashes, but (hopefully) only a small amount of time to calculate after a dump before the password is changed. However, if you are starting from scratch and have a single password to crack, there's no difference between a salted and unsalted password.
Modern state of the art for targeted attacks is to use slow hash algorithms, such as bcrypt. They have little effect on normal operations, as most users will get the right password within a few tries, so you're adding a negligible amount of time per user. But the extra time has a huge effect when an attacker is trying to calculate millions of hashes for a single user.
You can hash something like password+email+salt. If they don't know the email or salt it makes it hard to crack and even if they do it slows things down as they have to crack each password individually rather than making a rainbow table. Also using a slower hash like bcrypt rather than sha1 helps slow things down.
> What if the salt was derived from a key the user had to supply and wasn't stored anywhere?
If I understood you that is the same as demanding the user to input two strings for password authentication, one for salt and one for password, in which case you might just as well require the user to use a longer password.
Good point. Why do we have passwords anyway? Just to authenticate at unanticipated access points? We could always just do two-factor authentication for that. A code would be sent to Google Authenticator on your phone or something like that, encrypted with your public key, and you'd just decrypt it with your private key. The phone would be secured with your password or fingerprint, which is never sent anywhere. The code would allow you to auth with the new access point. If the cellphone was connected to the internet, it could send the key directly and the site would log you in. If not connected to the net, it could use bluetooth or optical or sound to communicate with the access point (eg web browser running on a computer) to send the code. Only in the worst case would you have to type anything in yourself.
Since most people walk around with their cellphones, you could even precompute a couple keys to unlock a site, for those times when there is no internet connection. Of course, your phone should be secured with a password and you should be able to revoke the keys if anything gets lost.
Because usernames and passwords can be implemented without reliance on 3rd party infrastructure and they are culturally accepted and understood - however poorly - by everyone. We're still using 80 character lines in programming because of IBM punch card design from 1928. Similarly, I doubt the password will completely go away within our grandchildren's lifetimes. That said, our mobile devices are likely to play an increasing role in authentication for everyday activities.
We use passwords both to authenticate (assert identity) and to authorize (declare intent). The problem with automated logins is that you cannot infer intent (i.e. you have no assurance that the user actually meant to log in to your service).
Modern state of the art for targeted attacks is to use slow hash algorithms, such as bcrypt. They have little effect on normal operations, as most users will get the right password within a few tries, so you're adding a negligible amount of time per user. But the extra time has a huge effect when an attacker is trying to calculate millions of hashes for a single user.