¿No es suficiente microtime () o mt_rand () para restablecer la contraseña?

Este documento muestra varios métodos de ataque en las funciones aleatorias de PHP. Al final del documento, puede encontrar un ejemplo de una función segura de generación de tokens.

No, mt_rand () y microtime () no son en absoluto seguros. Estos son los dos números de 32 bits. Una clave decente es completamente aleatoria (no es tiempo) y tiene un tamaño de al menos 128 bits. Además, mt_rand () no es criptográficamente seguro por lo que no produce números realmente aleatorios que puedan utilizarse para esta tarea.

Necesita obtener la clave de 128 bits de / dev / urandom, que es mejor, tiene 16 o 32 caracteres, y luego puede codificarla con sal o cifrar con AES utilizando otra clave simétrica de 128 bits, que puede obtener / dev / random, que es más lento, pero la entropía es mayor.

Usted describe el uso de microtime() y dice que un intento incorrecto invalida el token. Primero, un atacante intenta hacer un reinicio desde una cuenta que usted controla para ver cómo se genera el token. Tal vez descubren que parece una codificación de un conjunto de tiempo de unix en una zona horaria particular. El atacante intenta estimar el retraso del sistema (tiempo de red; tiempo de CPU). Sí, cualquier intento en particular es probable que falle. Pero si su atacante con su botnet intenta ~ 10 intentos por minuto, tomaría aproximadamente un día (si puede estimar el tiempo en ~ 0.1s antes de ingresar) o una semana (precisión de ~ 1 s).

Claro que posiblemente pueda bloquear la cuenta del mecanismo de restablecimiento de contraseña después de demasiados intentos incorrectos (pero, ¿cómo se desbloquearía?), ¿podría esto frustrar a los usuarios legítimos? Oh, ¿pones un captcha en la página? Sabemos que el atacante tiene que usar el pavo mecánico turco para derrotar al captcha a un costo de ~ $ 2 por cada mil captchas (por lo que cuesta ~ $ 20 entrar en una cuenta con un captcha). Pero nuevamente, si puede encontrar fácilmente nombres de inicio de sesión de una lista (por ejemplo, en la página de creación de la cuenta si le informa que un nombre de usuario ya está en uso), no tienen que atacar ninguna cuenta específica. Por ejemplo, cambian la cuenta que atacan casi siempre; posiblemente (con botnet) cambie la IP casi cada vez, etc.

En resumen, es bastante trivial implementar esto de manera segura a prueba de balas, así que, ¿por qué querrías hacerlo de forma insegura, donde esperas que cualquier atacante de la calle tenga un 1 en 100000 de entrar en un intento en particular? Versus conseguir alguna cadena aleatoria de 128 bits, donde tendrían un 1 en 000 000 000 340 000 000 000 000 000 000 000 000 000 oportunidad de adivinar al azar a él.

Este es uno de los casos fronterizos en los que, aunque uno no puede responderlo de manera definitiva con un claro, decidió "¡No! Así es como puedo romperlo". , todavía hay que decir "... pero ¿por qué quieres hacer esto si es tan fácil hacerlo bien?" .

¿Puede un atacante explotar microtime siendo usado como token? Al menos en teoría, la respuesta debe ser: "Definitivamente, y fácilmente" . No lo he intentado, así que no puedo decir con seguridad qué tan difícil es, pero es cierto que es posible.

¿Puede un atacante explotar microtime alimentado en mt_rand ? Posiblemente, poco probable, casi seguro que no. Al menos no con una gran probabilidad de éxito, y no sin un trabajo considerable. ¿Eso significa que es seguro? No.

Por otro lado, realmente no le cuesta nada a
a) usa un token con más bits (32 realmente no es mucho)
b) utilice un token que sea impredecible (generador aleatorio fuerte)

Yo usaría un token de 64 bits (128 si eres paranoico). El uso de un token de 128 bits es, por supuesto, mucho más seguro contra el forzamiento brutal, pero como los tokens tienen una vida útil limitada de unos pocos minutos y la cantidad de solicitudes que pueden enviarse a través de la red es limitada, 64 bits deberían estar bien (y en En caso de que el usuario deba ingresar la clave, esto significa que solo la mitad de la molestia para el usuario, también usar solo 64 bits agotará el generador de entropía más lentamente).

Si su servidor tiene un enlace ascendente gigabit, posiblemente no pueda recibir más de 1.1 millones de cuadros por segundo (asumiendo UDP y 8 bytes de carga útil). Si sus tokens son válidos por un tiempo "normal", como p. Ej. 15 minutos, la probabilidad de éxito de obtener un hit mientras se satura el enlace durante ese tiempo es 10 ^-11 . Además, aparte de la menor probabilidad de éxito, si alguien satura el enlace por completo durante varios minutos, es probable que esto no pase desapercibido. La configuración de una enorme botnet tampoco servirá de nada. Por supuesto, pueden hacer lo mismo, pero no importa qué, no hay más marcos que puedan atravesar el cable (limitación física).

Compare eso con un escenario en el que podría estar adivinando un token correcto de otro token que me ha enviado o que he escuchado a escondidas con una posibilidad de, digamos 1 en 100 (esto debería ser posible para un temporizador con la resolución de microtime ) simplemente mirando el reloj! O compárelo con un escenario en el que puedo derivar el estado de su generador de 623 mensajes consecutivos.

Incluso si es poco probable que tenga éxito a la vez, hay galaxias entre esto y un enfoque seguro (y ambos te cuestan lo mismo).