Protección contra credential stuffing en apps móviles

Qué es exactamente un ataque de credential stuffing

El atacante parte de una lista de pares usuario/contraseña filtrados de otro servicio y los prueba automáticamente contra tu API de login. No adivina nada: se apoya en que una parte de tus usuarios reutiliza contraseñas. Por eso funciona incluso con una política de contraseñas exigente.

Según el informe de Okta The State of Secure Identity 2023, uno de cada cuatro inicios de sesión analizados era un ataque de este tipo. La proporción sube en banca, fintech y comercio electrónico, donde una cuenta válida tiene valor inmediato.

El coste no aparece solo cuando el atacante acierta. Cada intento consume capacidad de tu backend y, si tu flujo envía un OTP antes de validar el origen, también SMS reales que pagas tú.

Por qué los controles habituales se quedan cortos

Los tres controles clásicos comparten el mismo punto débil: deciden a posteriori, sobre señales que el atacante puede manipular.

• Limitación por IP: se sortea repartiendo el ataque entre miles de proxies residenciales, cada uno con un puñado de intentos.
• CAPTCHA: penaliza al usuario legítimo en cada acceso y existe un mercado maduro de resolución automatizada y humana.
• WAF y puntuación de riesgo: funcionan con probabilidades, así que hay que elegir entre falsos positivos que bloquean clientes reales y un umbral que deja pasar el ataque.
• 2FA: solo interviene cuando la contraseña ya se ha dado por buena, de modo que el atacante ya sabe qué credenciales son válidas aunque no complete el acceso.

Qué cambia con un certificado por dispositivo

Con mTLS el servidor exige que el cliente presente su propio certificado durante el handshake TLS. Si no lo tiene, o no está firmado por tu cadena de CA, la conexión no llega a establecerse: tu aplicación nunca ve la petición.

Aplicado a móvil, eso significa que solo las instalaciones registradas de tu app pueden hablar con el endpoint de login. Un script, un cliente HTTP genérico o una copia recompilada de la app carecen de ese certificado, y ningún volumen de credenciales filtradas les sirve de nada.

Para el usuario legítimo el cambio es invisible: no hay casilla que marcar ni paso adicional. El coste se traslada íntegramente al atacante.

Qué hace falta para ponerlo en marcha

• Integrar el SDK en la app móvil para que cada instalación obtenga y renueve su certificado.
• Configurar el servidor de entrada (habitualmente Nginx) para exigir certificado de cliente en los endpoints sensibles.
• Decidir qué rutas lo exigen: normalmente el login y el registro, no los recursos públicos.
• Definir el procedimiento de revocación para los dispositivos que se den por comprometidos.