Hashing Passphrase en JavaScript del lado del cliente en lugar del lado del servidor - ¿Es viable?

Question

Hashing Passphrase en JavaScript del lado del cliente en lugar del lado del servidor - ¿Es viable?

#1 de Tom Leek (6 votos)

0

Se ha dejado otra pregunta sobre el sitio web de salting-and-hashing-for-web en el felpudo de StackExchange de Seguridad de la Información.

El enfoque que se menciona a menudo para el manejo de la contraseña del sitio web es usar un lenguaje del lado del servidor para emplear un algoritmo de hashing adecuado (ampliado o diseñado de otra manera para consumir demasiado los recursos informáticos), combinar con un salt al azar, y listo: a contraseña almacenada de forma segura. Estoy simplificando demasiado, por supuesto.

Si bien esto evita que las tablas de base de datos robadas contengan frases de contraseña potencialmente reutilizadas, todavía significa que la contraseña debe enviarse al servidor para que se haga hash, cuyo resultado se compara con el hash almacenado. SSL protege esto durante el transporte, naturalmente, pero todavía hay una ventana de la frase de contraseña de texto simple para que se realice el hash.

¿Qué pasa si el hashing tuvo lugar en el lado del cliente? El usuario seguiría usando una frase de contraseña que no coincide con el resultado final almacenado, y un individuo experto en tecnología que omita el JavaScript y envíe un hash directamente no lograría nada. Además, el hashing del lado del servidor podría implementarse para clientes que carecen de JavaScript. Al hacer esto, la carga del servidor se reduce y un servidor comprimido de forma encubierta aún no obtendría ninguna contraseña a medida que el sitio continuaba ejecutándose.

TL; DR: El único problema que puedo ver es que no se puede confiar en la asignación al azar del cliente para la sal. ¿Es esta la única razón por la que este enfoque no se recomienda más ampliamente?

web-application passwords salt cryptography javascript

pregunta Louis Jackman 04.02.2014 - 16:52

fuente

1 respuesta

Lea otras preguntas en las etiquetas web-application passwords salt cryptography javascript

código JS vulnerable? ¿El cifrado omitiría algunas reglas de firewall?

score 6 · Accepted Answer

El hash de contraseña debe aplicarse para hacer frente a la debilidad inherente de las contraseñas, es decir, la baja entropía. Si el hashing se produce en el cliente o en el servidor no importa mucho para la seguridad, siempre que se produzca en algún lugar entre el humano y el almacenamiento. Como el buen hashing de contraseña utiliza salt , el hashing almacenado del lado del servidor, del lado del cliente generalmente genera un viaje de ida y vuelta adicional (el cliente envía el nombre de usuario, el servidor envía el salt correspondiente, el cliente escribe la contraseña y envía el resultado). Además, dado que lo que el cliente envía es contraseña equivalente (que muestra que otorga acceso), y no desea almacenar los valores equivalentes de contraseña "tal como están" en su base de datos, aún debe hacer algo hash en el servidor, pero ese puede ser un hash simple, sin sal y sin escribir.

Sin embargo, el hash de contraseña con Javascript puede ser un problema: el hashing de contraseña es una carrera de armamentos entre el defensor y el atacante. La función de hashing de contraseñas se hace deliberadamente lenta para que la búsqueda exhaustiva sea costosa; pero esto hace que el uso de sea costoso para todos. Si el hashing se realiza en Javascript, entonces ocurrirá a la velocidad de Javascript, es decir, no muy rápido. En consecuencia, no podrá aumentar el número de iteraciones tanto como desee, en comparación con la situación en la que se produce el hash en el servidor.

Lo anterior es la respuesta genérica, pero los detalles pueden variar. Los intérpretes de Javascript tienden a a ser más rápidos con el tiempo. Más importante aún, un servidor dado puede tener que manejar muchos clientes simultáneamente, mientras que cada cliente solo tiene que preocuparse por sí mismo. Si el servidor debe manejar 100 clientes por segundo y aún así mantener el tiempo de autenticación dentro de un segundo, entonces no puede asignar más de 10 ms de su CPU por instancia de contraseña; mientras que con el hashing del lado del cliente, el cliente puede usar un segundo completo para él, lo que podría ser suficiente para compensar más que la lentitud de Javascript.

100 clientes por segundo es una cifra alta, y aunque algunos los clientes de Javascript parecen ser bastante rápidos, también hay clientes que no lo son (por ejemplo, personas con teléfonos inteligentes viejos: mi propio teléfono inteligente ejecuta Android 2.2, y el intérprete de Javascript en su navegador no es un campeón de carreras). Por esta razón, ahora mismo , parece que el hashing de contraseña del lado del cliente con Javascript no es (todavía) una idea ganadora. Esto puede cambiar en el futuro o en algunas situaciones específicas. Por ejemplo, el hashing del lado del cliente tiene el beneficio de mejorar mucho la resistencia del servidor a algunos ataques DoS ; Si la resistencia al DoS se considera más importante que la experiencia del usuario de un teléfono móvil, entonces el camino a seguir es el hashing del lado del cliente.

Para una introducción general al hash de contraseñas, incluidos los conceptos del lado del cliente y del servidor, consulte esta respuesta .