La diferenciación
visual es una consecuencia de la diferenciación de HTML. No puede suceder que el mismo HTML + JS + CSS conduzca a diferentes visualizaciones (a menos que se realicen algunas modificaciones intencionales, no sé ... ¿colores de fondo o animaciones dependientes del tiempo?).
Por lo tanto, puede enviar una cantidad suficiente de consultas para usuarios reales y comparar las mismas consultas para usuarios falsos; y debe hacer lo mismo con todos los puntos finales no autenticados que estén accesibles.
Esto significa examinar no solo la URL de "inicio de sesión" sino también la "Perdí mi contraseña, ¿cómo puedo recuperarla?".
Para cada uno de estos puntos finales, además de las diferencias en los resultados, calcule el tiempo promedio para responder y su varianza (una varianza suficientemente alta anulará cualquier tiempo razonable ataque).
Es posible que desee hacer esto dos veces, es decir, verifica el usuario "marcel" una y otra vez. La serie de los "primeros" que llamamos la serie unprimed , la serie de los "segundos" es la serie imprimada .
Purgue el contenido recibido de cualquier marca de tiempo, identificación única o información relacionada con el usuario (por ejemplo, "Lo sentimos, la contraseña para el usuario marcel es incorrecta" debería convertirse en "Lo siento, la contraseña para el usuario USERNAME es incorrecta". Aquí hay una expresión regular. Tenga cuidado si algunos el usuario se llama tabla, html o cuerpo, ya que eso distorsionaría los resultados).
Entonces, el resultado deseado es que, para todos puntos finales (1),
- todas las respuestas para usuarios reales y falsos son idénticas.
- las partes eliminadas ("marcel", "admin", "20160920173511.128", etc.) son todas idénticas o todas diferentes . No debe suceder que los usuarios reales obtengan una marca de tiempo real y los usuarios falsos no obtengan una marca de tiempo o una marca de tiempo con un formato diferente, por ejemplo.
- el tiempo para responder para cada usuario falso debe ser muy cercano al tiempo para responder para un usuario real. Lo ideal es que quieras la misma media y varianza.
- la distribución de tiempos para la serie imprimada y no impresa de usuarios reales podría ser diferente (por lo general, los tiempos imprimados son más cortos). Si lo son, entonces la misma proporción debe mantenerse entre las series imprimadas y no imprimidas para los usuarios falsos.
El punto 3 significa que buscar un usuario que no esté en la base de datos debe tomar el mismo tiempo que buscar un usuario que esté en la base de datos y tenga datos para cargar y analizar. Lograrlo no es trivial. He visto demoras aleatorias agregadas al proceso, pero deben basarse en el nombre de usuario (el mismo nombre de usuario = siempre la misma demora) (2).
El punto 4 podría conducir a un giro en los ataques de tiempo, permitiendo distinguir entre usuarios reales y falsos, incluso si en un solo intento los tiempos de reacción son los mismos.
(1) He visto varios sistemas que le pedirán a su nombre de usuario que lo ayude a recuperar la contraseña y que diga alegremente "¡Lo siento, ese nombre de usuario no se conoce!". Un mensaje más adecuado sería: "Muy bien, lserni (si esa es realmente tu cuenta), si estás en nuestra base de datos, recibirás un correo electrónico en breve".
(2) Cuando aparece un nombre de usuario, quiero agregar un retraso aleatorio que frustrará los intentos de la mayoría de cronometrar el proceso de autenticación. marcel se resuelve en 85 ms y enebro en 62 ms. ¿Es porque marcel existe y el enebro no, o porque sus retrasos fueron diferentes? No debes saberlo. Pero, ¿qué sucede si el retraso para el usuario de juniper es aleatorio cada vez ? Sucede que puedo promediar el tiempo de resolución y la aleatoriedad se cancelará lentamente (dependiendo de su varianza). Así que agrego al usuario juniper un retraso que fue asignado aleatoriamente a juniper, pero siempre es el mismo cuando Juniper intenta autenticar. Para evitar guardar cosas en una base de datos de huuuuuge, lo que realmente hago es calcular un CRC de 32 bits a partir del nombre, XOR con una sal secreta, usar el resultado para sembrar un PRNG y extraer un número aleatorio. En ese momento, incluso si el atacante sabe que los nombres de usuario existentes tienen un retraso de 50 ms, mientras que los nombres de usuario desconocidos obtienen 30, no puede saber si los 62 ms de Juniper se dieron por 50 más un 12 al azar (existe Juniper), o por 30 más un 32 al azar. (No hay enebro). Y el 12 (o 32) no será el mismo para un usuario diferente que tendrá un CRC32 diferente. Entonces, usar el mismo nombre de usuario no ayudará, pero usar un nombre de usuario diferente tampoco ayudará. Por supuesto, necesito un rango aleatorio lo suficientemente grande como para "abrumar" la diferencia horaria conocida / desconocida.