Autenticación segura: extensión parcial de la clave del lado del cliente ... revise / critique mi idea

El hashing del lado del cliente funciona, conceptualmente. El problema, sin embargo, es el de power . En un contexto web, el cliente usa Javascript, y Javascript es débil para las tareas intensivas de computación. El cliente ya utiliza un sistema que puede tener una CPU relativamente pequeña (podría ser un teléfono inteligente barato, por ejemplo), pero Javascript agrega su propia sobrecarga, que es enorme (porque se interpreta, difícil de JIT , y carece de tipos de enteros decentes). Como estimación aproximada, el hashing del lado del cliente en Javascript será 20 a 40 veces más lento que el hashing de contraseña en un servidor decente.

Desafortunadamente, la paciencia del usuario no se estira; El usuario tolera uno o dos segundos de retraso, no más. Por lo tanto, cuando utiliza el hashing del lado del cliente, tiene que usar menos iteraciones que cuando usa el hashing del lado del servidor, lo que debilita todo el panorama.

O, dicho de otro modo, siempre que maneje el proceso de inicio de sesión de no más de veinte usuarios por segundo , el hashing del lado del servidor le permitirá usar más iteraciones que el hashing del lado del cliente, y por lo tanto, ser mejor para la seguridad.

Si el cliente usa un applet de Java , es mucho más poderoso; el factor "20x" se convierte en "3x". Pero los applets de Java han pasado de moda y no funcionarán en tabletas y teléfonos inteligentes. Los clientes móviles con una aplicación dedicada pueden reactivar el concepto de hash de contraseña del lado del cliente.

En cuanto a los detalles , la mejor manera no es "eliminar una iteración" del algoritmo, sino agregar un hash adicional: los algoritmos criptográficos son animales complejos, y aunque la función de hashing de contraseñas se usa internamente "iteraciones", no necesariamente utilizan solo iteraciones. Por ejemplo, no puede eliminar fácilmente "la última iteración" de bcrypt y obtener un resultado parcial para ser transmitido al servidor. Entonces, en su lugar, realice todas las iteraciones en el cliente, envíe el resultado R al servidor, y el servidor almacena tanto el salt como el h (R) para alguna función hash h (por ejemplo, SHA-256).

SRP ya permite el estiramiento de la clave del lado del cliente porque tiene un KDF del lado del cliente. Si lo desea, puede pasar 15 minutos quemando ciclos mientras estira su clave, cada vez que inicia sesión, sin afectar el rendimiento del servidor.

Este es solo uno de muchos de sus beneficios.

Un defecto que puedo ver es que, como está haciendo la iteración n-1 en el lado del cliente, el uso de bcrypt / scrypt / PBKCDF no tiene sentido. Debido a que el uso de estos algoritmos es hacer que el craqueo de contraseñas consuma mucho tiempo y que el cómputo sea intensivo. En el escenario actual, un atacante tendrá el hash de iteración n-1 fácilmente disponible y además requerirá solo otra iteración 1 para adivinar la contraseña. Lo cual sería trivial para cualquier atacante y, según mi conocimiento, realizado en una simple máquina de escritorio.

Una posible solución para evitar el DoS es que, si alguien (usuario malintencionado) desea iniciar sesión en la cuenta, luego de un cierto número de intentos puede detener al usuario para que inicie sesión durante cierto tiempo y siga aumentando este tiempo de manera exponencial. Por ejemplo, deje que los intentos de umbral sean 3. Si un usuario con el nombre de usuario 'user123' está ingresando, (s) ingresa 3 contraseñas incorrectas, luego puede bloquear la cuenta durante 5 segundos. Si nuevamente se produce un intento incorrecto después de 5 segundos, puede bloquear las cuentas durante 10 segundos y así sucesivamente.

De esta manera, se asegura de que un usuario no esté acaparando su recurso y haciendo que cualquier ataque de fuerza bruta consuma tiempo y, finalmente, sea inviable.

EDITAR: Otro problema con este enfoque es que está enviando la sal al lado del cliente. La sal se utiliza para dificultar el forzoso de las contraseñas. En el escenario actual, el atacante también tendrá la sal correspondiente al nombre de usuario fácilmente disponible.

Además, si el cliente desactiva el javascript, entonces él / ella no podrá iniciar sesión en el sitio web. Pero esto puede no ser un problema importante, ya que los sitios web modernos dependen en gran medida de los javascripts y requieren que se habilite en el cliente.

Con una función de derivación de clave lenta, desea alcanzar dos objetivos:

Evita que un atacante pueda iniciar sesión

El hash iterado del lado del cliente, puede verse como un reemplazo de contraseña en sí mismo, que se envía al servidor y se vuelve a hash y se almacena. Si un atacante puede encontrar este reemplazo de contraseña, podría iniciar sesión. Dado que la salida del hash pre-iterado (BCrypt) es de aproximadamente 60 caracteres (con 7 caracteres constantes y 21 caracteres de sal conocidos), todavía habría más de 1E50 combinaciones para probar, por lo que el forzamiento de los brutos parece impracticable.

Evita que un atacante obtenga la contraseña original, puede usarla en otros servicios web

Para averiguar la contraseña original, un atacante aún tendría que hacer todas las iteraciones. Por lo tanto, las iteraciones realizadas en el lado del cliente ralentizarán los ataques de diccionario (prueba de contraseñas de uso frecuente).

En realidad, su esquema parece funcionar, al menos no puedo ver un defecto evidente. Sin embargo, hay un problema con BCrypt, este algoritmo usa la contraseña original y el salt en cada iteración, por lo que no podría hacer una iteración más, en lugar de eso tendría que calcular un hash adicional en el servidor.

Por favor, lea también la respuesta de Thomas Pornin, hay razones prácticas para hacer el lado del servidor de hash (y él es el experto).