¿Qué está mal con este sistema de autenticación?

Supongo que los ID de usuario se atribuyen de forma aleatoria y uniforme entre los 2 ³² posibles valores de 32 bits. En ese caso, lo mejor que puede hacer un atacante es probar las ID de usuario potenciales (valores de 32 bits) en cualquier orden hasta que se encuentre la correcta. Si hay una ID de usuario válida de N , el número promedio de intentos que el atacante deberá realizar estará cerca de 2 ³² / (N + 1) : si hay mil usuarios, entonces el atacante necesitará conectarse aproximadamente 4 millones de veces a su servidor antes de que se le otorgue acceso. Una vez que el atacante obtiene acceso, puede reutilizar la ID a voluntad.

Su única defensa en ese caso es tratar de detectar dicho forzamiento brutal, por ejemplo. al prohibir las direcciones IP de las que provienen demasiados intentos fallidos. Esto tiene limitaciones; en particular, cuando muchas personas están detrás de algún tipo de proxy web o NAT , pueden, desde su punto de vista, compartir La misma dirección IP, por lo que corre el riesgo de desactivar una pérdida de usuarios con una estrategia de bloqueo. A la inversa, los atacantes pueden alquilar botnets para realizar su fuerza bruta única desde muchas direcciones IP distintas.

Una forma de verlo es, de hecho, considerar que el ID de usuario es algún tipo de contraseña; en esa vista, el atacante puede atacar las contraseñas de todos los usuarios simultáneamente. El nivel de seguridad se reduce así cuando hay más usuarios, como se puede ver en la expresión matemática anterior: más usuarios significa más objetivos para el atacante, sin aumentar el costo de búsqueda.

Una estrategia de inicio de sesión + contraseña es lo que hace la mayoría de las personas. Esto es mucho mejor: cuando se trata de forzar una contraseña bruta, el atacante debe seleccionar un nombre de usuario específico, y podrá romper solo esa contraseña específica. El "nombre de usuario" es una información no secreta que es específica para cada usuario. Con los nombres de usuario, la tarea del atacante ya no es mil veces más fácil cuando hay miles de usuarios. En cuanto al "token de sesión", hay varios métodos que son más o menos equivalentes (token en la URL, token como parámetro POST, token como encabezado HTTP, también conocido como "cookie"), y pronto); SSL en sí mismo tiene su propia noción de sesión y podría reutilizarse.

Resumen: el "ID de usuario secreto" sin estrategia de nombre de usuario puede ser seguro, pero solo si el espacio de la posible ID de usuario es lo suficientemente grande como para vencer la fuerza bruta , incluso si hay muchos ID de usuario válidos. Esto requiere un ID de usuario grande que debe seleccionarse de manera aleatoria y uniforme. 128 bits serían suficientes. 64 bits me pondrían bastante nervioso. 32 bits son demasiado pequeños.

El argumento fácil es que 32 bits están bien dentro de los límites de fuerza bruta, dependiendo de cuántos ataques por segundo sea posible, probablemente tomará algo en el rango de una semana a un año para buscar en todo el espacio. Divida ese tiempo por el número de usuarios y tendrá un marco de tiempo aproximado para que el atacante encuentre una cuenta.

No conozco los detalles de la implementación, una aceleración de solicitud de inicio de sesión por IP hace que el ataque sea más difícil, pero probablemente no lo suficiente. ¿Es posible deducir el espacio de ID simplemente mirando el código público? En este momento, su mejor defensa puede ser que no mucha gente sepa que todas las ID de usuario son enteros. No es algo en lo que confíe, pero un ataque de fuerza bruta de diccionario sin el conocimiento de los enteros sería mucho más difícil.

Además, quien haya escrito este código en primer lugar, obviamente, no está muy preocupado por la seguridad, parece probable que haya otros problemas. Solicitud de falsificación en sitios cruzados, inyecciones de SQL, o tal vez incluso algún código C "rápido" con un agotamiento del búfer de la vieja escuela.