The salt's 100% server side - the client never knows about it, or even if his/her password is being salted and hashed, or stored in plaintext (unless they're able to send you your password - then you know it's stored in plaintext).
When someone is trying to get into the system by brute force, are they not just throwing a ton of passwords (even via rainbow tables) at the established authentication system?
It depends how they're trying to break into the system, but typically no. If they're trying to send lots of login attempts against the the established authentication system, that's something you as a server admin can detect. To protect against it, you can rate limit requests from that ip address. For example: the first 3 password attempts within n-seconds execute as fast as your servers can handle, but on every subsequent attempt you delay the response by a quarter second, then a half second, then a full second, then two seconds, etc. If they try too often, you can ban the ip address**, and possibly have the server send out a message to the admins.
It seems to me that the client would have to know the salt ahead of time (i.e. some time well before they even try to log in) to create a secure salted password to send to the login service. And wouldn't this then be kind like a pseudo public key encryption? If the client doesn't have the salt then they are just sending a plain password which gets salted/concatenated once it reaches the server (you would need to do this from what you say so that you can compare the provided password to what is stored in the DB). So then the hacker only needs to brute force it.
If you were to have the client send up the salt with their password (or hash it themselves), you'd be correct. But the server's the one who generates and stores the password, and the client never sees it or knows about it.
And if you provide them the salt during the login process (i.e. not ahead of time) they still only need to figure out or throw a bunch the plain passwords at the server... brute force it.
True, but you can detect when something is sending thousands or more password attempts at a server and block it.
And if they aren't trying to brute force things through the established app API, then presumably they are attacking say the database directly. And then they can get your data directly.
Exactly; almost all these comments assume the attackers have gained access to your database. The idea is that even if they can get your data directly, they still won't be able to figure out a user's login credentials. Depending on what your site does, that may or may not be a big deal for your users. As a user, if they got a copy of my profile on linkedin, I wouldn't care too much. It'd be bad, sure, but not the end of the world. If they could figure out my password and log in to the site, and start posting as me, that's a problem. Same thing with banking credentials (knowing my balance vs. being able to change my balance), and most places where I need a password.
The other problem is password reuse. Many users reuse their passwords on multiple sites. That means if you can crack a million user's linkedin accounts, you now have their email + passwords. If you then try logging into gmail with those same emails + passwords, you might get in to 100,000 of them. And then you can try their other accounts (say, banking) and even if those fail, you can try to do a password reset, and if you own their email address you can usually "confirm" the reset and set their password to whatever you want.
Do you know any good documents online that explain how this works? Salting that is. I'm still not sure how it really helps. It sounds good in theory. But I guess until I find something that explains it well, I still don't see how to implement it effectively. I have looked, but other than a bunch of posts telling people to concatenate a salt with the password, there isn't much out there as far as I can tell.
I learned a lot of this first at college, then over time as I've seen how people implement their systems. Wikipedia has some info on salting, but mostly it's rehashing what I've said (http://en.wikipedia.org/wiki/Salt_(cryptography)). Doing a quick google search, this page seems to do a very good job at explaining this stuff: http://crackstation.net/hashing-security.htm. Just remember this all assumes they have access to your database. The only extra thing I'd add to what they describe is to also include an application password secret that's stored in your config files (or some other place outside your database). That way if they only have your database but not your config files, they won't be able to break any passwords. To do that just do $applicationPwSecret+$salt+$password instead of $salt+$password. Order doesn't matter, as long as your consistent across every password (i.e. $salt+$password vs. $password+$salt)
**Do take care when banning an ip though - there are lots of legitimate reasons users can share ip addresses. Some ISPs put their users behind NATs, as might schools and some countries.
"Home life as we understand it is no more natural to us than a cage is to a cockatoo." -- George Bernard Shaw