Ataque de Tiempo: El Peligro de un Código que Responde "Demasiado Rápido"
El arte de escuchar la cerradura
Imaginemos la clásica escena de una película de robos: el ladrón se pone un estetoscopio, pega la oreja a la caja fuerte y empieza a girar la perilla despacio. Busca escuchar un pequeño "clic" que le indique que un número es correcto, permitiéndole adivinar la combinación.
En el desarrollo web, los atacantes hacen algo similar para robar contraseñas o firmas digitales. Solo que en lugar de escuchar "clics", miden milisegundos. A esta técnica se la conoce como Ataque de Tiempo (Timing Attack).
En un ataque de tiempo, el hacker mide cuánto tarda el servidor en rechazar una clave para ir adivinándola letra por letra.
El problema: La comparación "perezosa"
Para entender este ataque, veamos cómo se suele comparar texto a bajo nivel.
Cuando usamos el operador normal de igualdad (dependiendo del lenguaje y el runtime) para comparar una contraseña ingresada con la real, el sistema suele ser "perezoso" para ahorrar recursos. Compara letra por letra.
Si la clave real es SECRETO y probamos con XECRETO, el sistema ve que la "S" no coincide con la "X" y corta la comparación inmediatamente. Esto tarda, a modo ilustrativo, 1 milisegundo.
Pero si probamos con SACRETO, el sistema compara la "S" (coincide), y luego falla en la "A". Como hizo un paso más, tarda una pequeñísima fracción de tiempo extra: digamos 1.1 milisegundos.
El ataque
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 (analizando la latencia y filtrando el "ruido" de la red).
Cuando nota una micro-demora sistemática, sabe que "acertó" esa letra (escuchó el clic de la caja fuerte). Así va adivinando la clave paso a paso.
La solución: El tiempo constante y mitigaciones
Para evitar esto, necesitamos cambiar la cerradura por una completamente silenciosa. En código, esto se logra usando funciones de comparación de tiempo constante (como crypto.timingSafeEqual en Node.js).
Estas funciones obligan al procesador a comparar toda la cadena de principio a fin, sin importar si la primera letra ya falló. Así, el servidor tarda exactamente el mismo tiempo en responder, dejando al atacante a ciegas.
En proyectos profesionales, complementamos esto con defensas adicionales: uso estricto de Rate Limiting (para evitar miles de intentos automatizados), bloqueos temporales, y cifrado con sal (hashing). Proteger una aplicación implica asegurar que el código no filtre información a través de sus tiempos de respuesta.
