¿Por qué el hashing de una contraseña en el lado del cliente es tan poco común?

Inventor del hashing de contraseña de JavaScript aquí

En 1998, estaba construyendo un Wiki, el primer sitio web que había creado con un sistema de inicio de sesión. No había forma de poder permitirme el alojamiento con SSL, pero me preocupaba que las contraseñas de texto simple estuvieran en Internet. Leí sobre CHAP (protocolo de autenticación de hash de desafío) y me di cuenta de que podía implementarlo en JavaScript. Terminé publicando JavaScript MD5 como un proyecto independiente y se ha convertido en el código abierto más popular que he desarrollado. La wiki nunca llegó más allá del alfa.

En comparación con SSL, tiene varios puntos débiles:

• Solo protege contra escuchas pasivas. Un MITM activo puede manipular el JavaScript y deshabilitar el hashing.
• Los hashes del lado del servidor se convierten en equivalentes de contraseña. Al menos en la implementación común; hay variaciones que evitan esto.
• Los hashes capturados pueden ser forzados brutalmente. En teoría, es posible evitar esto utilizando JavaScript RSA.

Siempre he expuesto estas limitaciones por adelantado. Solía flamearme periódicamente por ellos. Pero mantengo el principio original hasta el día de hoy: si no tiene SSL por alguna razón, es mejor que las contraseñas de texto simple. A principios de la década de 2000, varios proveedores grandes (en particular, Yahoo!) utilizaron esto para los inicios de sesión. Creían que SSL, incluso solo para los inicios de sesión tendría una sobrecarga excesiva. Creo que cambiaron a SSL solo por los inicios de sesión en 2006, y alrededor de 2011 cuando se lanzó Firesheep, la mayoría de los proveedores cambiaron a SSL completo.

Entonces, la respuesta corta es: El hash del lado del cliente es raro porque las personas usan SSL en su lugar.

Todavía hay algunos beneficios potenciales del hashing del lado del cliente:

• Algunos programas no saben si se implementará con SSL o no, por lo que tiene sentido incluir hash. vBulletin fue un ejemplo común de esto.
• Alivio del servidor: con hash computacionalmente costosos, tiene sentido para el cliente realizar parte del trabajo. Consulte esta pregunta .
• Administradores maliciosos: el hashing del lado del cliente puede evitar que los administradores maliciosos vean las contraseñas de texto sin formato. Esto generalmente se descarta porque un administrador malintencionado podría modificar el JavaScript y deshabilitar el hashing. Pero para ser justos, esa acción aumenta sus posibilidades de ser detectada, por lo que hay algo de mérito en esto.

En última instancia, aunque estos beneficios son menores y añaden mucha complejidad, existe el riesgo real de que presente una vulnerabilidad más grave en su intento de mejorar la seguridad. Y para las personas que desean más seguridad que una contraseña, la autenticación multifactor es la mejor solución.

Entonces, la segunda respuesta corta es: porque la autenticación de múltiples factores proporciona más seguridad que el hashing de contraseñas del lado del cliente.

Para comprender este problema, primero debe comprender por qué las contraseñas de hash. Es completamente posible almacenar una contraseña en texto plano en un servidor y simplemente comparar la contraseña transmitida a la contraseña recibida. Mientras la contraseña esté protegida en tránsito, este es un medio seguro de autenticación (secreto compartido).

La razón por la que las contraseñas están en hash es porque el problema no es la autenticación, sino el almacenamiento. Si el servidor alguna vez se ve comprometido, el atacante tendría acceso inmediato a todas las cuentas de usuario, ya que ahora sabrían el secreto utilizado para la autenticación de los usuarios.

Hashing actúa como una barrera para esto. Dado que el servidor no conoce la entrada real requerida para la autenticación, incluso un compromiso con la base de datos no otorga a un atacante acceso a las cuentas de usuario. Todavía tendrían que averiguar la entrada para dar para alcanzar los valores hash con los que la aplicación verifica. Claro que podrían alterar todos los valores a algo que saben, pero esto generaría sospechas rápidamente y el sistema se cerraría y se aseguraría.

Entonces, el problema con el hashing del lado del cliente es que efectivamente hace que el resultado del hash sea la contraseña en lugar de la contraseña. No hay nada que impida que un atacante omita al cliente oficial y simplemente envíe el hash final al servidor directamente. No proporciona seguridad adicional (o pérdida) durante la autenticación, pero en la situación en la que el hash está diseñado para proteger, no ofrece nada, ya que el hash almacenado en la base de datos es en realidad el secreto compartido transmitido al servidor.

Dicho esto, hay dos cosas notables que el hashing del lado del cliente te da. Si bien no ayuda en absoluto a proteger su sistema, puede ayudar a proteger a su usuario. Si no está transmitiendo la contraseña con seguridad o si la transmisión se ve comprometida sin que el código del cliente se vea comprometido, seguirá protegiendo la contraseña del usuario (que pueden reutilizarse en otros sitios) para evitar que se filtre.

La otra es que puede proporcionar iteraciones adicionales de un hash para hacer que un ataque fuera de línea contra la base de datos sea más difícil sin tener que usar ciclos de servidor, pero aún necesita suficientes ciclos de servidor para protegerse contra un cliente no autorizado. Una vez más, la protección principal que ofrece esta es evitar que se descubra la contraseña original, pero no hace nada para ayudar a proteger el mecanismo de autenticación de su sitio.

Dicho de otra manera, si bien proporciona algunas protecciones menores, desde el punto de vista del servidor, el hash del lado del cliente debe tratarse como si fuera la contraseña directa del usuario. No proporciona ni más ni menos seguridad en el servidor que si el usuario hubiera dado su contraseña directamente y debería estar protegido como tal.

Si desea poder proporcionar ese nivel adicional de seguridad, recomendaría dos hashes. Hash una vez del lado del cliente para crear una contraseña nueva y única, luego hash esa contraseña en el servidor para hacer un valor que almacena en la base de datos. De esta manera obtienes lo mejor de ambos mundos.

En su mayor parte, se confía en SSL lo suficiente como para proteger el intercambio de que el hash inicial antes de la transmisión se considera innecesario y un servidor comprometido siempre podría alterar el código enviado al cliente para que no se realice el hash inicial . Simplemente no es una alternativa efectiva a SSL y no ofrece suficiente ventaja adicional para valer los costos y la complejidad.

Si tiene bastantes ventajas, debería incluirlas en su pregunta para que la gente descubra si son realmente útiles (y puede que se haga famoso si es así)

La gente no está a favor del hashing del lado del cliente porque tiene mejores formas de proteger la información privada de los usuarios. Pensemos en los lugares con posibles fugas de información y hay tres de ellos:

• El cliente.
• Entre el cliente y el servidor.
• El servidor.

Entonces veamos por qué o por qué no el hashing del lado del cliente ayudará en estos lugares.

• El cliente.

  Si hay malware en su propia computadora, por ejemplo, si su navegador está comprometido o si su computadora está implantada con un software de registro de claves, el hashing del lado del cliente no evita que un pirata informático obtenga su contraseña. La razón es obvia.

• Entre el cliente y el servidor.

  Existe el canal de comunicación entre el cliente y el servidor. Si hay un interlocutor que escucha la comunicación, el hash del lado del cliente puede dificultar la filtración de la contraseña, ya que tiene que recuperar la contraseña original del hash. De hecho es útil aquí.

  Sin embargo, esta vulnerabilidad se basa en el presupuesto de un canal de comunicación inseguro. En realidad, hay protocolos cuya existencia intenta resolver este problema exactamente. Su tarea principal es establecer un canal seguro sobre uno inseguro. El ejemplo más famoso y ampliamente implementado es SSL / TLS, y proporciona más funcionalidad y mejor seguridad que el hashing del lado del cliente.

  La conclusión es que el hashing del lado del cliente es útil en el canal, pero aquí hay mejores herramientas.

• El servidor.

  La información de los usuarios puede filtrarse en el servidor si un pirata informático compromete al servidor. El pirata informático puede obtener contraseñas de usuario de la base de datos si están almacenadas en texto sin formato. Es por eso que hoy en día la mayoría de los servidores no hacen eso. En su lugar, almacenan hashes de contraseñas para que los piratas informáticos no puedan restaurar fácilmente las contraseñas originales a partir de la información que tienen a mano (es decir, hashes).

  Puede sentirse tentado a creer que las cosas todavía funcionan bien si el servidor simplemente almacena los hashes computados en el lado del cliente. Pero esto es muy malo. En esa situación los hashes se convierten en equivalentes de contraseña. El hacker puede pasar la autenticación simplemente entregando el hash sin revertirlo. El objetivo de un hacker no es revertir un hash, sino entrar en tu cuenta. La importancia radica en el proceso de verificación del servidor en los datos del cliente, no en el hecho de que los datos son un valor de hash. Por lo tanto, el beneficio del hash del lado del cliente es trivial aquí y el servidor debe reiniciar de todos modos.

Para resumir, el hashing del lado del cliente es útil para proteger la información del usuario, pero la protección se aplica en gran medida al canal de comunicación. Debido a que tenemos mejores enfoques allí (SSL / TLS), la aplicación de hashing del lado del cliente está enormemente suprimida. Simplemente no es la mejor herramienta para la tarea en cuestión.

¿Qué ventajas tendría el hash de contraseña del lado del cliente?

Bueno, la contraseña no se enviaría a través de la red en texto simple. Pero realmente debería estar utilizando el cifrado TLS cuando inicie sesión, por lo que la detección de contraseñas no debería ser un problema.

Otra razón podría ser que no desee que el servidor alguna vez tenga en cuenta la contraseña del usuario, ni siquiera por un microsegundo. Eso significa que le da al servidor el hash de contraseña en el registro y luego inicia sesión con ese hash de contraseña. Desafortunadamente, esto no resuelve nada: el secreto compartido para iniciar sesión en la cuenta ahora es el hash, no la contraseña. Cuando obtiene conocimiento del hash, puede iniciar sesión sin saber la contraseña real (porque el servidor tampoco lo sabe).

Es una buena práctica hacer hash en el lado del cliente, luego agregar la contraseña y el hash nuevamente en el lado del servidor. Esta es una capa extra de protección contra el hombre en los ataques medios. SSL es la primera capa; sin embargo, las revelaciones de Snowden dejaron en claro que SSL puede ser comprometido por organizaciones como la NSA con relativa facilidad.

Ya que estás hablando de una aplicación web ...

En una base de datos tenemos una tabla llamada dbo.useracc, estamos almacenando estos hashes de contraseña

User        Password
--------       ----------
user1       5f4dcc3b5aa765d61d8327deb882cf99
user2       202cb962ac59075b964b07152d234b70
user3       098f6bcd4621d373cade4e832627b4f6

y nuestra función de inicio de sesión en la aplicación web será algo como

if (user == $user and password == $pass) {
           return auth.token
}

Digamos que un atacante hackeó con éxito y robó la base de datos y guardó nuestros datos dbo.useracc. Ahora tiene nuestra contraseña hash.

Si el proceso de hashes de inicio de sesión se almacena en el cliente, el atacante aún puede acceder a su cuenta con la contraseña hash simplemente conectando el método HTTP POST modificando el campo de la contraseña para enviar su contraseña y el usuario aún puede iniciar sesión. Recuerde que los datos de su aplicación se están comunicando con el servidor a través del método POST, eventualmente después de que se haya verificado el hash.

Sin embargo, si el proceso de hashing está en el servidor, es otra historia.

$pass = md5.hash($pass);

if (user == $user and password == $pass) {
           return auth.token;
}

Si el pirata informático usa la contraseña con hash para iniciar sesión, será una "contraseña con hash" para el hash con una contraseña con hash.

En este caso, digamos la publicación del atacante

$ usuario = usuario1 $ pass = 5f4dcc3b5aa765d61d8327deb882cf99

Después de que el servidor haga $ pass = md5.hash (5f4dcc3b5aa765d61d8327deb882cf99) devolverá '696d29e0940a4957748fe3fc9efd22a3', que devolverá una declaración falsa.

Esto es para cercar al atacante que ha robado con éxito los datos de la base de datos y trata de acceder a través de la aplicación web usando la contraseña con hash. Y, por supuesto, el atacante aún puede piratear las cuentas si realiza con éxito la fuerza bruta / descifra los hashes mediante ataques de diccionario y demás. Sin embargo, el hacker requiere más tiempo si la contraseña es una buena contraseña después de comprometer el sistema y el administrador del servidor podría simplemente restablecer la contraseña y enviar un correo electrónico a los usuarios.

También se usa para amenazas internas como empleados en una empresa. En una empresa, habrá un administrador de base de datos y desarrolladores. Son roles diferentes. Ahora, para evitar que los usuarios empleados accedan a los datos confidenciales, necesitan tener acceso tanto a la aplicación como a la base de datos para acceder a los datos. Por supuesto, podría argumentar que un DBA aún puede alterar los datos de la base de datos a través de la propia base de datos, pero los desarrolladores no pueden acceder a ellos y es más fácil identificar de dónde proviene el ataque. Se trata de derechos de control de acceso y minimización de riesgos y amenazas.

Aunque el tema tiene algunos puntos de filtración concretos, como lo señaló @Cyker, la discusión es un poco rápida aquí ... Me gustaría agregar un punto que no vi mencionado.

Es simplemente que si hash lo antes posible, reduce los riesgos de programación de pasar accidentalmente una contraseña de texto sin cifrar que no debería ir. Ya tomamos medidas como cadenas seguras y matrices seguras para intentar destruir el texto claro lo antes posible; y el hash en el momento en que se obtiene la contraseña es otra medida como esa ... A medida que el código evoluciona, los riesgos parecen reducirse.

Acabo de escribir un pequeño "Cuadro" de C # que toma el texto claro de SecureString y lo pulsa de inmediato, de esta manera simplemente sé que nunca se registrará ni pasará a una biblioteca que no espero. No se trata tanto de un protocolo, sino del programador que está sentado y mirando una contraseña, ¡no quiero tocarla! (Todavía es una contraseña equivalente en algunos aspectos, pero al menos se oculta inmediatamente de la locura como mover un paréntesis de cierre en una llamada de método encadenado y pasar un texto claro al lugar equivocado. Y una matriz segura aún no está oculta).

Creo que el hash del lado del cliente tiene un lado positivo y un inconveniente:

pro: oculta la contraseña en caso de dns / phishing / lo que sea útil para el usuario, ya que la mayoría de las personas reutilizan las contraseñas en varios servicios. Como dijeron otros desarrolladores, esto no hace nada por tu propia seguridad.

contras: su servidor no obtiene la contraseña, lo que evita que se advierta al usuario sobre la seguridad de la contraseña. Sé que algunos dirán que esto puede / debería ser del lado del cliente, pero cuando tiene varios clientes, puede ser bueno centralizar el lado del servidor.

Voy a saltar aquí con el propósito expreso de ponderar a favor del mecanismo de hashing del lado del cliente. Veamos cómo nos beneficia esto:

lado del cliente: Ninguna mejora.

En tránsito: Protege la contraseña en el caso de SSLstrip en el que la contraseña termina siendo transmitida en texto claro. Sin embargo, si se implementa HSTS, la mayoría de la gente diría que SSLStrip no tendría ningún efecto. ¿Derecha? No.

En la entrada al servidor: Por último, vemos el mayor beneficio. ¿Qué pasa si alguien ha comprometido el servidor? Obtienen un flujo continuo de contraseñas de texto simple si simplemente inician Wireshark / TCPDump y exportan la clave privada del servidor. Ahora pueden sentarse en el cable durante un par de meses y, para los servidores de gran volumen (millones de registros de usuarios por mes), obtienen una brecha masiva de texto simple. Esto es asumiendo que es más valioso obtener las contraseñas de las personas en el servicio que tener RCE en su servidor, por supuesto.

En el servidor: Beneficios de rendimiento si no tiene que ejecutar bcrypt en cada contraseña entrante, lo que descarga algunos costos computacionales en el cliente sin introducir nuevas vulnerabilidades. Esto parece ser algo bueno para el administrador de su servidor, así como los costos de hardware.

Sin embargo, parece que la mejor práctica sería incorporar el hash de contraseñas en el lado del cliente a menos que genere tiempos de carga de página insoportables para los usuarios.

creo que la probabilidad de ser hackeado en el lado del cliente es más alta que en el lado del servidor. (Porque hay algunos expertos en TI que cuidan el servidor). Si tu computadora ya está siendo hackeada. Los piratas informáticos también pueden ser robados por el pirata informático. Además, ya que sus algoritmos ya no son un secreto. Creo que se vuelve inútil.