I think the parent was assuming a lovely world where all passwords would be large randomly-generated strings. In that case, salting is no better than just increasing the size of the randomly-generated string, right?

Yes, thanks. And the thing is they don't even have to be that long. Still inconvenient to enter a bunch of those every day, but the same is true with any password and most of us don't do that - we maybe set a master password and our web browser remembers them.

Salting is one of the best and easiest measures if there is a possibility of lowish entropy passwords, but if not it doesn't help (edit: on further thought I think there is a fairly substantial entropy range where the only viable attack is a very large scale batch attack and salting would prevent that, although the cost/benefit on actually doing that makes it an unlikely attack anyway). Iteration and memory hard functions also effectively add just a few bits of entropy. But when users choose passwords, a huge portion will be low enough entropy that nothing you can do will help enough.

A second factor does help in that case, and can provide additional protection to high entropy passwords (as long as the second factor is distinct from the system that stores the high entropy password, which in theory it should be to be called a second factor).

technion: yeah, my suggestion won't work if there is any way for the user to set the password.