I've been trying to research authentication systems to model my own project around, but I feel like I'm misunderstanding something significant.
There is a lot of talk about using a per-user salt to hash the password, and this makes sense as a defence mechanism. But almost all info I see about this is done on the server side (back end). This implies that the front end is sending the password as plaintext, which I thought was a no-no.
Then I see discussion of salting the password at the front end (client-side before sending the login to the backend for authentication). This seems to solve the problem of sending the password in plaintext, but introduces the problem that the password must be hashed with the same salt each time in order to match the hashed password stored in the back end. This implies either a site-wide salt, or that the front end is getting access to the user salt.
The latter seemed feasible for a second, but this seems the same as publishing the per-user salt, as the front end needs to access the salt prior to authentication.
Can anyone tell me what I am not understanding?
Salting the password, before it is hashed and saved to the DB, is meant for better protection of the saved password. If someone manages to steal your password DB, when passwords are salted, it will be much harder for them to reverse the hash and get the raw password value.
This has nothing to do with the security of passwords on the front channel. You can send passwords in plain text from your front channel to the backend if you use TLS. The request is encrypted and thus protected from eavesdroppers. You will still be vulnerable if you have a man-in-the-browser or an XSS attack, as the attacker will have access to the plain-text password before TLS encryption is applied. However, hashing the password in the frontend app will most probably not protect you from these attacks anyway.
To sum up: