¿Un servidor autenticado que considera que la contraseña de texto simple es un problema grave?

Como han señalado otros, el hash del lado del cliente realmente no resuelve el problema, ya que el servidor todavía ve algo que se puede reutilizar para autenticarse (a través de un ataque de paso de hash). Sigue siendo mejor que pasar la contraseña de texto simple, ya que las personas reutilizan las contraseñas (pero no los hashes con sal) entre sitios / servicios, e incluso cuando no lo hacen, a menudo usan contraseñas similares (/ sistemas de elección de contraseñas / etc).

Por cierto, esto no es solo un problema de seguridad del servidor. La intercepción TLS (por parte de los dispositivos de seguridad de la red del lado del cliente) se está volviendo muy común, y cualquier dispositivo que realice la intercepción también tiene acceso a las contraseñas o hashes.

Afortunadamente, existe una solución: el intercambio asimétrico de claves autenticadas por contraseña (PAKE) permite la autenticación sin exponer ni almacenar nada equivalente a una contraseña en el servidor (o en un dispositivo de intercepción). Secure Remote Password (SRP) es el protocolo PAKE más conocido y más popular. También hay una nueva propuesta de protocolo PAKE, llamada OPAQUE que se ve aún mejor (aunque quiero ver el ritmo de la comunidad criptográfica en él por un tiempo antes de que lo usara). Matthew Green tiene un buen resumen de este aquí .

Desafortunadamente, los PAKE no son muy conocidos o utilizados. En mi opinión, esta debería ser la forma estándar de realizar la autenticación de red.

Ah, y hay una gran limitación: si esto se implementa en JavaScript suministrado por el servidor, alguien con suficiente acceso (o un cuadro de intercepción de TLS) puede modificar el JavaScript que se envía al cliente para filtrar la contraseña. Hay maneras de mejorar esto (por ejemplo, con la integridad del sub-recurso), pero incluso sin esos PAKE al menos reducir la vulnerabilidad.

Exponer la contraseña simple siempre es un problema, a veces más y otras menos. Si el atacante logra poner en peligro el servidor, podría agarrar las contraseñas cuando el servidor compruebe si son correctas. Registros de depuración extensos similares en el servidor también podrían registrar inadvertidamente las contraseñas ingresadas, de modo que un atacante podría tomarlas del disco del servidor o de copias de seguridad externas.

Por lo tanto, podría ser una buena idea proteger la contraseña contra el servidor también. Solo que esto no es fácil, ya que el servidor finalmente necesita la contraseña o algo equivalente para autenticar al usuario.

Una forma no sería enviar la contraseña original del cliente al servidor, sino usar un algoritmo para obtener la contraseña del lado del servidor de la contraseña ingresada por el usuario, una función de derivación de claves (KDF). Esto es como sugieres con h(p) . Por supuesto, esta clave derivada debería tener la misma protección del lado del servidor que tendría una contraseña de texto simple, ya que es esencialmente una contraseña de texto simple, pero no tan fácil de adivinar. Esto significa que la clave derivada debe almacenarse correctamente con contraseña con hash en el lado del servidor. Si esta clave derivada depende del dominio de los servidores o de cualquier otra cosa específica del sitio, al menos podría proteger un poco contra la reutilización de la contraseña, ya que la misma contraseña dará como resultado una clave derivada diferente según el sitio. Por supuesto, si la clave se obtiene a partir de la clave en el código provisto por el servidor, entonces un atacante podría cambiar este código para obtener también la contraseña original, pero esto requiere más esfuerzo y, por lo tanto, este método reduce el riesgo total.

Aún mejor sería si la contraseña solo se usa localmente en el cliente para proteger un certificado de cliente dentro del navegador y luego usar la autenticación mutua en https. En este caso, no sería suficiente que el atacante atacara el servidor, pero cada cliente tendría que ser atacado. Por otro lado, los certificados del lado del cliente son más una molestia que emplear que una simple contraseña y, por lo tanto, rara vez se utilizan. En otras palabras: menos riesgo a costa de menos facilidad de uso.

Aparte de eso, también hay métodos de desafío-respuesta como Digest-MD5. Solo estas funciones de resumen tienen el problema de que la contraseña del usuario o algo equivalente deben almacenarse en el lado del servidor sin la protección que ofrece el hashing de contraseña unidireccional habitual, lo que aumenta la superficie de ataque allí.

Otras respuestas y comentarios ya han revelado que la seguridad del mecanismo de autenticación realmente no cambia al aplicar primero una función hash (incluso puede reducirse si las contraseñas de entrada largas son comunes).

Me gustaría señalar que ocultar la contraseña original puede proteger a los usuarios y sus estrategias de creación de contraseña.

Los usuarios que tienen la misma contraseña para muchos sitios pueden beneficiarse del hashing si se incluye una clave específica del sitio. Los esquemas de generación de contraseñas aplicados por un usuario (como "mypw4site1.com", "mypw4site2.com", ...) también están ocultos para cualquier persona en el medio.

Por supuesto, cualquier información personal que pueda estar contenida en la contraseña (como nombres o fechas de nacimiento de familiares) también se oculta.

Al enviar un hash de la contraseña, en lugar de la propia contraseña, todo lo que está protegiendo es el texto claro de la contraseña. Esto tiene algún mérito, pero no hace nada para proteger contra los ataques de repetición, esto se conoce como pass-the -hash .

Al combinar la contraseña del usuario con un salt (desafío) de un solo uso provisto por el servidor, puede protegerse contra dicho ataque, pero para validar el token presentado (h (p + c)), el servicio necesita para volver a crear el mismo valor de hash, es decir, debe almacenar el texto sin formato de la contraseña. Eso no es bueno.

Convencionalmente, un servicio de autenticación almacenará un hash de la contraseña con un salt generado aleatoriamente (h (s + p)), junto con el texto claro del salt. El texto claro de la sal no se considera particularmente secreto: la efectividad del mecanismo no se debilita mucho al revelar esto. Entonces, en principio, el servidor podría enviar un desafío y el cliente enviaría de vuelta:

 h(h(s+p)+c)

Lamentablemente, esto no resuelve el problema de pasar el hash, ya que el conocimiento de los datos (h (s + p)) almacenados en el servidor es suficiente para poder autenticarse.

La única forma práctica de evitar el problema es usar un servicio de autenticación confiable tanto para el cliente como para el servicio de la aplicación, por ejemplo. utilizando kerberos o openid, que solo traslada el problema al servicio de autenticación, pero esto separa y disocia las responsabilidades.