En general, las sales y los hashes se realizan en el lado del servidor, no del lado del cliente. La comunicación entre el servidor y el cliente debe estar protegida con cifrado (TLS). Como lo menciona Anders en un comentario, esto puede responder muchas de sus preguntas: Para una aplicación web HTTPS, ¿vale la pena cifrar la contraseña antes de enviarla por POST, para evitar que un atacante MITM la capture?
Sobre las sales y el hash en general: la idea detrás de las sales y los hashes a menudo se reduce a obligar al atacante a realizar un algoritmo de fuerza bruta. Este (a) compra el tiempo de servicio para proteger la red y cambiar las contraseñas de los usuarios, y (b) evita que los actores malos dentro de la empresa / sitio web adquieran la contraseña del usuario (para cosas malas como probar esa contraseña en otros sitios).
Las sales hacen muchas cosas. (1) protege contra ataques de la tabla del arco iris, como usted dijo, (2) en el caso de violación de datos, hace que el craqueo de contraseñas sea más difícil que el hash de vainilla (es decir, no hay forma de que un atacante pueda construir una base de datos de todos los hashes para un algoritmo; tendrían que tener esa base de datos para cada hash, lo cual no es factible); esto le da tiempo al sitio / a los usuarios para cambiar el algoritmo y las contraseñas, (3) evita que las personas que trabajan en el sitio puedan robar fácilmente la contraseña de un usuario y (4) otorga más opciones de arquitectura para asegurar el proceso de autenticación.
Para hablar de (4) por un minuto, un cliente mío (internacional muy grande) tenía una arquitectura de microservicio, y sus procesos de autenticación funcionaron al mezclar la contraseña con una de las muchas sales (basadas en el nombre de usuario) antes enviándolo al microservicio que verificó la base de datos real. Este tipo de separación impidió que el código que maneja la base de datos conozca tanto el salt como la contraseña, y el microservicio que sabía que el salt no mantendría los hashes (ni en la memoria ni en el disco). Un atacante no pudo usar un volcado de base de datos; necesitarían software de base de datos y de más de un servidor . Esto aumenta la complejidad, ya que una base de datos robada no los acerca al hash de la base de datos; también necesitarían la lista de sales (de otro servidor). Ningún empleado tuvo acceso a ambos servidores, lo que ayudó con (3).
Por qué el hashing del lado del cliente no es super útil :
Un hombre en el ataque central puede capturar lo que se transmite entre el cliente y el servidor. Hashear la contraseña antes de enviar hace muy poco; el atacante no tiene que ser capaz de generar el hash, solo tendría que enviar la misma solicitud de nuevo para obtener acceso.
Por ejemplo, veamos las siguientes solicitudes y parámetros (no estoy usando encabezados HTTP reales para facilitar la lectura):
POST /auth/login
[email protected]
pass=mypassword
versus:
POST /auth/login
[email protected]
pass=89e01536ac207279409d4de1e5253e01f4a1769e696db0d6062ca9b8f56767c8
El servidor no puede saber por el hash que la contraseña real es "mypassword", por lo que solo usará el hash como está para verificar la cuenta del usuario. Un atacante que puede leer esa solicitud no necesita saber que su contraseña es "mypassword", solo necesita tomar el hash; Eso no da ninguna protección para la cuenta. Lo único que esto impide es que el atacante pueda probar la contraseña en otros sitios (por ejemplo, muchas personas usan tontamente el mismo correo electrónico y contraseña para google y su banco).