Qué es el credential stuffing y por qué el 2FA no lo detiene

Cómo funciona el ataque, paso a paso

Primero se consigue el material: listas de pares usuario/contraseña procedentes de filtraciones de otros servicios, que circulan agregadas y depuradas.

Después se automatiza el envío contra tu endpoint de login, repartido entre muchas direcciones IP para que ninguna supere tu umbral de bloqueo. El atacante no necesita una tasa de acierto alta: le basta con que una fracción pequeña de tus usuarios reutilice contraseñas.

Por último se separan las credenciales que funcionan. Esa lista validada es el producto: se explota más tarde, o se vende.

Por qué el 2FA llega tarde

Un segundo factor se pide después de dar la contraseña por buena. En ese momento el atacante ya ha obtenido lo que buscaba en esta fase: saber que la credencial es válida. Que no complete el acceso no le impide anotar el par como bueno.

Hay además dos efectos secundarios que se subestiman. El primero es el coste: si el segundo factor es un SMS, cada intento con contraseña correcta dispara un mensaje que pagas tú, y existe un fraude específico que explota justamente eso, el llamado SMS pumping. El segundo es la fatiga de notificaciones: bombardear a un usuario con peticiones de confirmación acaba consiguiendo que alguna se apruebe.

Qué sí lo corta

Un control que actúe antes de la validación de la contraseña, y que no dependa de una señal que el atacante pueda imitar. Ahí es donde encaja la autenticación del cliente: si el endpoint de login solo acepta conexiones de instalaciones registradas de tu app, el ataque no tiene por dónde entrar, porque su cliente no tiene certificado que presentar.

• Actúa en el handshake TLS, antes de que tu aplicación procese la petición.
• No depende de reputación de IP ni de huellas del cliente, que son manipulables.
• No añade fricción al usuario legítimo, a diferencia de un CAPTCHA.
• No sustituye al 2FA: lo complementa, quitándole el trabajo que no le corresponde.