Tenga en cuenta que las estadísticas de THC-Hydra se realizaron en una máquina que se describe como ejecutando SuSE Linux 7.2. En la historia de las distribuciones de Linux SuSE / SuSE / SUSE / openSUSE , esto nos remonta a mediados de 2001, por lo que El punto de referencia probablemente se hizo en una máquina de esa época. La tecnología ha mejorado desde entonces, y las velocidades de computación han aumentado.
Un "servicio web remoto débil" típico utilizará la autenticación básica HTTP, posiblemente dentro de un túnel SSL (es decir, que es HTTPS, no HTTP). Cada vez que adivine la contraseña implica lo siguiente: enviar un encabezado HTTP que contenga la contraseña presumida (por ejemplo, 200 bytes para el encabezado) y luego obtener una respuesta de error (un código de error 401, con un encabezado que probablemente será menos simplificado para el tamaño que el el atacante elige; digamos 1 kB de cabecera). Como HTTP admite keep-alive , la conexión TCP (o el túnel SSL / TLS) se puede reutilizar inmediatamente para otro intento; en particular, esto significa que no habrá una sobrecarga notable en presencia de SSL. 1000 intentos por segundo luego requieren un ancho de banda de aproximadamente 200 kB / s al servidor, 1 MB / s del servidor; eso es un ancho de banda de 10 Mbit / s e incluso los servicios de hosting baratos ofrecen mucho. En redes locales, 100 MBits / s o más son la norma. No hay problema de ancho de banda aquí.
Por supuesto, el atacante debe intentar establecer un paralelismo para evitar la latencia. No es necesario esperar la respuesta del servidor antes de enviar otra solicitud. Aquí, la paralelización significa abrir cien conexiones al servidor de destino y ejecutarlas en paralelo. Los sistemas operativos, hoy en día, pueden manejar muchos miles de conexiones abiertas; Cien no morirán de hambre la máquina.
Del lado del servidor, dado que todos los intentos apuntan al mismo usuario, la contraseña (con hash) estará en la RAM (normalmente se almacena en un archivo o base de datos, pero la RAM se usa como caché para los datos a los que se accede con frecuencia, y durante una contraseña) sesión de cracking que el elemento de datos será muy a la que se accede con frecuencia). Ya que estamos hablando de un servicio web remoto débil , el servidor almacenará las contraseñas "tal cual" o las procesará con una función hash simple, no algo como bcrypt . Al volver a revisar cada contraseña entrante se utilizará una CPU despreciable (una PC anémica puede calcular millones de hashes por segundo, por lo que 1,000 hashes por segundo no son nada). Del mismo modo, el análisis del encabezado HTTP no utilizará mucha CPU.
Por lo tanto, 1000 conjeturas de contraseña por segundo parece una cifra altamente factible; en realidad, no debería ser demasiado difícil superarlo por un gran margen. Tenga en cuenta los puntos importantes en la discusión anterior:
- El atacante puede establecer un paralelismo, ya que tiene muchas contraseñas que probar.
- La autenticación ocurre muy temprano en el procesamiento de una solicitud entrante, por lo que no se aplican los costos normales de procesamiento de las solicitudes (para cualquier funcionalidad que proporcione el servicio web).
- El uso de la función de hashing lento (como bcrypt) puede ser efectivo en tal situación.