¿Por qué los servidores almacenan la contraseña con hash en lugar de transmitir en clave privada / pública?

Si está hablando específicamente sobre aplicaciones web (según la etiqueta), incluso con el cifrado / cifrado de contraseñas del lado del cliente, sigue siendo tan vulnerable a los usuarios intermedios como con el envío de una contraseña directa.

Esto se debe a que un ataque man-in-the-middle puede sabotear el script del lado del cliente en su camino desde el servidor al cliente, para hacer que haga algo más que el paso de la contraseña deseado protegido por cifrado. El usuario final nunca lo notaría (ya que se necesitaría un experto en depuración de JavaScript para determinar que esto había ocurrido).

Para defenderse contra MitM, tendría que tener un código de confianza integrado en el navegador (o un complemento) en lugar de un JavaScript del servidor. Esto podría ser, por ejemplo, Autenticación de compendio de HTTP .

Sin embargo, en general, si tienes MitM en contra de la aplicación, entonces ya casi has perdido. Incluso con un esquema de autenticación de estilo de compendio seguro, aún sería capaz de imitar cualquier acción que el usuario pudiera realizar en la aplicación, anular la contraseña al momento de configurar / cambiar, o simplemente cambiar la interfaz de la aplicación para solicitar la información de contraseña. página.

Es por esto que la mayor parte del esfuerzo se ha puesto en mantener todo el canal seguro (con SSL) en lugar de la protección de contraseña específicamente. No es que SSL sea perfecto, obviamente ...

Este esquema es razonable. No hay nada terriblemente malo en ello. Sin embargo, no parece tener ventajas claras ni convincentes sobre la "mejor práctica" actual: a saber, enviar un nombre de usuario / contraseña a través de un canal autenticado con SSL, con la contraseña almacenada en forma de hash en el servidor.

No es más seguro si la base de datos del servidor se filtra, porque la clave pública + sal del usuario (almacenada en la base de datos del servidor en su esquema) le permite a un atacante montar ataques de diccionario en la contraseña del usuario de la misma manera que una contraseña hash hace.

No es más seguro contra los ataques de intermediarios, por las razones que explica @bobince.

Significa que la contraseña del usuario nunca abandona su computadora y nunca se almacena en texto sin cifrar en la memoria del servidor (ni siquiera temporalmente). Sin embargo, es probable que esto no sea un beneficio suficientemente grande como para estimular la adopción, ya que esto no parece hacer mucha diferencia para los tipos de ataques que prevalecen en la actualidad.

En principio, su enfoque podría ser más seguro contra el phishing, si fuera compatible con los navegadores de forma nativa, y si los navegadores pudieran encontrar alguna IU que garantice que los usuarios escriban su contraseña solo en la IU del navegador y no se dejen engañar en escribirlo en un sitio web. Sin embargo, en la práctica, los exploradores no admiten esto, y hay un problema de gallina y huevo con la implementación (los exploradores no implementarán algo así hasta que muchos sitios lo admitan, y los sitios probablemente no lo implementarán por su cuenta sin soporte de navegador). Además, no está completamente claro cómo diseñar una interfaz de usuario del navegador para evitar estos ataques de suplantación de identidad y phishing.

Conclusión: es más complicado que solo enviar un nombre de usuario / contraseña a través de SSL, y no proporciona suficientes beneficios para garantizar ese esfuerzo de desarrollo.