Ataque de Tiempo: El Peligro de un Código que Responde "Demasiado Rápido"

Imaginá la clásica escena de una película de robos: el ladrón se pone un estetoscopio, pega la oreja a la puerta de una caja fuerte y empieza a girar la perilla muy despacio. Está buscando escuchar un pequeño "clic". Ese sonido le indica que un número es correcto, permitiéndole adivinar la combinación completa número por número.

En el mundo del desarrollo web, los atacantes hacen exactamente lo mismo para robar contraseñas o tokens de seguridad. Solo que en lugar de escuchar "clics", miden milisegundos. A esta técnica se le conoce como Ataque de Tiempo.

El Problema: La Comparación "Perezosa"

Para entender cómo funciona el ataque, hay que entender cómo comparan texto los lenguajes de programación por defecto.

Cuando usamos el operador normal de igualdad (como === en JavaScript) para comparar una contraseña que ingresó el usuario con la contraseña real, el sistema es "perezoso" para ahorrar recursos. Compara letra por letra de izquierda a derecha.

Si la clave real es SECRETO y el atacante prueba con XECRETO, el sistema ve que la "S" no coincide con la "X" y corta la comparación inmediatamente, devolviendo un error. Esto tarda, por ejemplo, 1 milisegundo.

Pero si el atacante prueba con SACRETO, el sistema compara la "S" (coincide), y luego falla en la "A". Como hizo un paso más, tarda un poquitito más: digamos 1.1 milisegundos.

El Ataque: Escuchando los Milisegundos

El atacante automatiza miles de peticiones cambiando una letra a la vez. No le importa el mensaje de "Contraseña incorrecta", le importa cuánto tardó el servidor en responder.

Cuando nota que el servidor tardó una fracción de milisegundo más, sabe que "acertó" esa letra (escuchó el clic de la caja fuerte). Así, letra por letra, va adivinando la clave completa sin tener que probar todas las combinaciones posibles, reduciendo un trabajo de años a unas pocas horas.

La Solución: El Tiempo Constante

Para evitar que nos roben usando un cronómetro, tenemos que cambiar la cerradura de nuestra caja fuerte por una que sea completamente silenciosa. En código, esto se logra usando funciones de comparación de tiempo constante (como timingSafeEqual en Node.js).

Lo que hace esta función es obligar al procesador a comparar toda la cadena de texto de principio a fin, sin importar si la primera letra ya falló.

Si la clave es incorrecta en la primera letra o en la última, el servidor va a tardar exactamente el mismo tiempo en responder. Al estandarizar el tiempo de respuesta, le quitamos al atacante la capacidad de medir diferencias. Lo dejamos completamente a ciegas (o sordo, siguiendo nuestra analogía).

En MiWebIdeal, aplicamos este nivel de detalle en la seguridad de nuestros desarrollos. Sabemos que proteger una aplicación no se trata solo de poner contraseñas largas, sino de asegurar que el código mismo no esté filtrando información a través de sus tiempos de respuesta. Es la diferencia entre una puerta que parece segura y una verdadera caja fuerte.