¿El hecho de que el servidor de contraseñas no tenga un hashing significa que un sitio web comprometido podría dejar las contraseñas vulnerables?

La debilidad a la que alude es real. Un punto importante es que una vez que el servidor está comprometido, el atacante tiene pocos incentivos para capturar las contraseñas que otorgan acceso al servidor ese , ya está en el lugar. Sin embargo, los usuarios humanos tienen el hábito de reutilizar las contraseñas, y ese es un gran problema, porque una contraseña reutilizada significa que los compromisos en un servidor tienden a "propagarse", exactamente de la forma que lo explica: el atacante toma la contraseña P para el usuario U , y adivina (por desgracia, la mayoría de las veces) que el mismo usuario U usará la misma contraseña en otros servidores.

Hashing del lado del cliente es una buena idea, pero hay detalles :

• Lo que sea que el cliente envíe al servidor, ya sea la propia contraseña o la contraseña con hash, otorga acceso. Es contraseña equivalente . Si el servidor almacena estos hashes "tal cual" en su base de datos, entonces se encuentra en la misma situación que un servidor que almacena las contraseñas de texto simple, y eso es malo. Por lo tanto, el servidor DEBE hacer también un hash.

• El hashing del lado del cliente solo se produce si hay un código en el lado del cliente que realiza el hashing. En un contexto web, esto significa JavaScript. Desafortunadamente, JavaScript es pobre en implementaciones criptográficas; en particular, es bastante lento, por lo que el hashing del lado del cliente no podrá usar las muchas iteraciones que normalmente se necesitan para el buen hashing de contraseña (consulte this para más detalles). Además, esto no funcionaría para clientes sin JavaScript.

• Aún en un contexto web, el hashing del lado del cliente, si se produce, se realiza mediante el código JavaScript enviado por el servidor . Si el servidor se ha sometido a un control hostil, puede enviar un JavaScript malicioso que pretende hacer el hashing, pero no lo hace. El usuario no será el más sabio. Por lo tanto, el problema de raíz no se resuelve.

El hashing del lado del cliente generalmente se visualiza bajo el nombre de "alivio del servidor", no para aumentar la seguridad contra los servidores malvados, sino para permitir que el servidor maneje muchos usuarios concurrentes sin gastar toda su CPU en muchos hashing. JavaScript es lo que es, esto no se hace comúnmente en la actualidad.

Así que hay dos partes separadas para esto.

Primero, el servidor se ve comprometido, y segundo, el envío de hashes al servidor en lugar de las contraseñas.

Para la primera parte con el servidor comprometido, sí, el atacante podría hacer casi lo que quiera. Si son dueños del servidor, pueden obtener los nombres de usuario y las contraseñas de los usuarios que se pasan al servidor. Esta es la razón por la que los servidores deben reforzarse contra los ataques y actualizarse periódicamente para que ofrezcan la menor superficie de ataque posible.

Para la segunda parte, si tiene el cliente antes de calcular el hash, entonces ese hash se ha convertido literalmente en la contraseña. Si un atacante hubiera robado la base de datos de hashes (pero no ha comprometido el servidor web), no necesita encontrar las contraseñas que se convierten en esos hashes; simplemente puede enviar el hash al servidor web, y se autenticará ya que el servidor ya estaría esperando un hash como entrada para comparar con su base de datos.

Es probable que no pueda evitar una modificación simple del lado del servidor del código enviado a los clientes para que se ejecute si su servidor es de su propiedad.

Sin embargo, si esto es parte de un paquete de software preinstalado o pre-distribuido con distintos componentes de cliente y servidor (esto podría incluir aplicaciones web con componentes descargados que permanecen residentes en el sistema operativo del cliente), el hashing del lado del cliente podría ser útil para la sensación de que, aunque es probable que el atacante aún pueda usar esos hash para la autenticación en SU base de datos (o simplemente para restablecer las contraseñas como se menciona en uno de los comentarios), ya no tiene acceso fácil a la contraseña de texto simple que se enviaría a su servidor ( sobre SSL) para hashing salado y almacenamiento de base de datos.

Por lo tanto, si tiene un cliente que usa la misma contraseña en varios lugares, siempre que el hash no sea reversible trivialmente , su compromiso con el servidor en particular ya no revela las credenciales que el atacante puede usar en otro lugar. . Esto se mejoraría con la distribución aleatoria del lado del cliente (para que no termines con el mismo hash que generaría el mismo algoritmo para ese texto simple).

Encuentro que muchas personas (especialmente en el reino de PHP ) no entienden lo que hace el hashing. Aquí está la metodología

1. El usuario crea una cuenta y le envía un combo de nombre de usuario / contraseña (de manera segura a través de HTTPS, espero)
2. La contraseña está en el servidor (con un salt aleatorio) y se almacena con el nombre de usuario
3. El usuario vuelve más tarde e ingresa su contraseña de texto simple
4. El servidor encuentra el hash almacenado para el nombre de usuario. Con $2y hashes (BCRYPT), el costo y la sal se almacenan en la misma cadena. Por lo tanto, utilizando el mismo costo y sal, el servidor genera un hash con la contraseña provista por el usuario (recuerde, los hashes son de una sola vía por diseño)
5. Si todo es igual, si el hash generado coincide con el hash almacenado, podemos autenticar al usuario

Suponiendo que alguien hackee su servidor, sus usuarios estarán mejor protegidos porque el salt es aleatorio para cada hash. Como tal, tendría que aplicar una fuerza bruta a cada contraseña por separado (la teoría central detrás de cualquier tipo de seguridad es aumentar el costo de hacer algo hasta el punto en que alguien no lo intente). Los sistemas de hash SHA1 y MD5, que antes eran populares, casi siempre se generaban sin sal, lo que los hace susceptibles no solo a las debilidades del hash en sí, sino a los ataques de tabla de arco iris (sin sal, cada SHA1 y MD5 es el mismo para una cadena dada) .

Realmente no hay manera de hacer esto del lado del cliente porque

• El cliente está en manos del enemigo. Así que tendrías que enviar al cliente todo lo que necesitan para generar el hash (especialmente el salt) y luego hacer que devuelvan el hash.
• Como se mencionó en otra respuesta, en ese momento su hash se convierte en la contraseña porque eso es lo que te envían. En otras palabras, aunque no sepa cuál es la contraseña, todavía estás haciendo una simple comparación de cadenas en lugar de generar un hash seguro para poder ingresar

No, el elemento Inspeccionar o algo similar existe en la mayoría de los navegadores, lo que permite que cualquier persona omita el código del lado del cliente. Si un pirata informático tuviera acceso a la base de datos, podría eliminar el código de hashing utilizando Inspect Element e ingresar los hashes como contraseñas, o editar la página para no hash de todos modos. ¿Qué tal un script que detiene el servidor si detecta que una página ha sido modificada por un pirata informático?