Beneficios del hashing de contraseñas del lado del cliente sobre otros mecanismos de seguridad [duplicado]

Como se ha mencionado, definitivamente comienza leyendo esta pregunta:

Hashing Frase de contraseña en JavaScript del lado del cliente en lugar del lado del servidor: ¿es viable?

Creo que eso responde a tus primeras preguntas. Sin embargo, creo que tiene una pregunta adicional aquí que no ha sido respondida en esa pregunta. Parece que también está preguntando "¿Qué pasa si el hash fue realizado por el navegador y solo se envió una contraseña con hash y con sal al servidor o incluso se pudo acceder a ella a través de javascript?".

Este es un enfoque completamente diferente para la autenticación de contraseña, y creo que tiene una serie de problemas, tanto teóricos como prácticos.

El problema práctico es simple. No hay una forma realista de llegar de donde aquí para allá. Si el sistema que está proponiendo se implementó en este momento, literalmente cada sitio web se rompería. No hay nadie que use este método porque este método no existe (estoy diciendo lo obvio, lo siento). Como resultado, podría imaginar a los proveedores de navegadores incorporando gradualmente nuevas funciones para hacer que algo como esto suceda. Tal vez agregamos un nuevo tipo de entrada: ¿el tipo de entrada hashed ? Esto actúa como una entrada de contraseña, pero cualquier intento de obtener su valor a través de javascript, o enviar su valor a un servidor, simplemente resulta en una contraseña con hash, con su salt. Sin embargo, tal cosa podría nunca ser forzada realista sobre el desarrollador web. En su lugar, tendrían que optar por usarlo. Por lo tanto, esto no sería "seguro por defecto", sino el mismo "seguro por elección" que intenta evitar con esta sugerencia. Como resultado, diría que, prácticamente, no hay forma de hacer lo que se quiere hacer.

Si pudiéramos hacer que esto sucediera (tal vez con un esfuerzo concertado para actualizar los navegadores de los usuarios a la última versión, el tiempo de migración de los sitios web y luego dejar de usar el campo de la contraseña anterior), ¿realmente ayudaría? Estoy dudosa El problema es que ahora tiene sus procedimientos de inicio de sesión de sitios web estrechamente acoplados a su navegador de los usuarios. Simplemente no veo que eso vaya bien a largo plazo. Teniendo en cuenta la gran cantidad de problemas de compatibilidad del navegador con los que las aplicaciones web ya tienen que lidiar, realmente dudo que el acoplamiento de la parte más importante de su aplicación (el inicio de sesión) con el navegador real vaya a funcionar sin problemas. ¿Qué sucede cuando el algoritmo de hash utilizado por el navegador está en desuso? ¿Cómo le indica el navegador al servidor que el hash ha cambiado porque el algoritmo ha cambiado? ¿Qué sucede si un navegador se ha actualizado al último algoritmo (debido a que el algoritmo anterior tuvo vulnerabilidades expuestas), pero el usuario usa otro navegador que no se ha actualizado?

Puedo prever que algo como esto causa muchos más problemas de los que resuelve.

Por otra parte Creo que esto pierde el panorama general. La razón principal por la que usamos las contraseñas de sal y hash es para proteger al usuario contra las filtraciones, ya que muchas personas reutilizan las contraseñas en los sitios. Sin embargo, si vamos a comenzar a implementar soluciones basadas en el navegador para minimizar el impacto de este problema, estoy seguro de que podemos encontrar algo más en conjunto que sea más conveniente y más seguro. Creo que estás usando la herramienta incorrecta para resolver el problema incorrecto.

Además de que @Sefa ya proporciona una gran lectura, hay un beneficio en el sentido de que si el servidor es malicioso y no sal + hash tu contraseña (o un administrador intercepta el tráfico) y eres lo suficientemente tonto como para usar el La misma contraseña en muchos sitios, al agregar sal y hash al lado de su contraseña, evitará que un servidor malicioso robe su contraseña en otros sitios.

Además de este escenario, no puedo pensar en ningún uso del hashing del lado del cliente cuando se combina con TLS y el hashing salado del lado del servidor fuerte en un servidor confiable.

No sé exactamente lo que quiere decir con "hash de contraseña del lado del cliente". ¿Simplemente quiere decir que, en el lado del cliente, toma su contraseña normal, a la que finalmente le agrega sal y la trama, para "inventar" una nueva contraseña, que es la "contraseña real" utilizada? ¿O quiere decir: una especie de prueba de conocimiento cero en un diálogo con el servidor que tiene la ventaja de que incluso si está conectado al servidor incorrecto, no traiciona su contraseña?

En el primer caso, no veo la utilidad original en comparación con un administrador de contraseñas. Se necesita la sal y su contraseña normal, así que en lugar de almacenar la sal en un "administrador", ¿por qué no almacena una contraseña aleatoria en ese mismo administrador? Y como la sal no tiene entropía, no hace que su contraseña sea más segura. La entropía de una contraseña no aumenta por hash. No veo la distinción entre usar sales almacenadas y una contraseña común, o almacenar cadenas aleatorias en un administrador de contraseñas, desbloqueado con dicha contraseña.

El segundo caso es mucho más interesante, pero necesita que el servidor coopere porque se convierte en una prueba de conocimiento cero de la contraseña.