El hash en el cliente solo tiene sentido si no confía en el servidor de alguna manera y no quiere mostrarle la contraseña "real" (la que recuerda el usuario humano). ¿Por qué no querría mostrar la contraseña en el sitio en el que dicha contraseña tiene algún uso? Debido a que ha reutilizado la contraseña en otro lugar! Ahora, por lo general, es mala, pero existe una versión relativamente segura que se encarna en innumerables extensiones de navegador o marcadores como esta o esa (no 'No responda por su calidad). Estas son herramientas donde el usuario humano recuerda una "contraseña maestra", a partir de la cual se genera una contraseña específica del sitio, utilizando el nombre de dominio del sitio como una especie de sal, para que dos sitios distintos obtengan contraseñas distintas.
Si bien este escenario tiene sentido, hacerlo con Javascript enviado por el propio servidor no lo hace. De hecho, el punto del hashing del lado del cliente de contraseña es que el servidor es potencialmente hostil (por ejemplo, subvertido por un atacante) y, por lo tanto, el código de Javascript enviado por ese servidor es, como mínimo, sospechoso. No desea ingresar su contraseña valiosa en un Javascript hostil ...
Otro caso para el hashing del lado del cliente es sobre hashing lento . Dado que las contraseñas son, por definición, débiles, usted quiere frustrar los ataques de diccionario . Usted asume que el malvado obtuvo una copia de la base de datos del servidor y "intentará las contraseñas" en sus propias máquinas (consulte esta entrada de blog para una discusión sobre esto). Para ralentizar al adversario, emplea un proceso de hashing inherentemente lento (como bcrypt ), pero esto hará que el procesamiento sea lento para todos, incluido el servidor. Para ayudar al servidor, es posible que desee descargar parte del trabajo en el cliente, por lo tanto, realice al menos parte de él en algún código Javascript que se ejecute en el navegador del cliente ...
Desafortunadamente, Javascript es muy lento en este tipo de trabajo (generalmente de 20 a 100 veces más lento que el código C decente), y el sistema cliente no podrá contribuir una parte sustancial al esfuerzo de hashing. La idea es sólida pero tendrá que esperar por una mejor tecnología (habría funcionado con un cliente Java , sin embargo: con una JVM decente, el código Java optimizado es de 2 a 4 veces más lento que el código C optimizado , para un trabajo de hashing).
Para resumir, no hay un caso realmente bueno para realizar el hashing de contraseñas del lado del cliente, a partir del código Javascript enviado por el propio servidor. Simplemente envíe la contraseña "tal como está" al servidor a través de un túnel HTTPS (la página de inicio de sesión, la URL de destino del formulario y cualquier página que esté protegida por la contraseña, todas se entregarán a través de SSL; de lo contrario, tienen problemas de seguridad más urgentes que el uso de contraseñas).