El phishing y el robo de credenciales no son «problemas de contraseñas». Son problemas de flujo de trabajo. Los atacantes tienen éxito porque los flujos de autenticación siguen dependiendo de secretos reutilizables, de la confusión humana y de rutas de recuperación que se pueden manipular.

La autenticación passwordless cambia esta ecuación al eliminar la contraseña del flujo de usuario y sustituirla por una prueba criptográfica. Ese cambio no hace que los ataques sean imposibles, pero obliga a los adversarios a cambiar de táctica. Muchos ataques de credenciales de alto volumen se vuelven menos rentables, y los caminos más débiles pasan a ser más fáciles de identificar y controlar.

Un recordatorio de modelado de amenazas: qué quieren realmente los atacantes

La mayoría de los ataques de credenciales buscan uno de estos tres resultados:

1. Credenciales reutilizables (contraseñas, códigos OTP, secretos de recuperación)
2. Una sesión válida (tokens o cookies que se puedan reutilizar)
3. Un bypass de recuperación (override del helpdesk, compromiso de un enlace de restablecimiento)

Passwordless reduce directamente la primera categoría y hace que la segunda y la tercera sean más fáciles de defender, porque el sistema depende menos de secretos compartidos.

Para un mapa de definiciones de MFA, passkeys y passwordless, consulta: Passwordless vs MFA vs passkeys: cuál es la diferencia real (y en qué se equivocan las empresas)

Ataque 1: phishing de adversario-en-medio (AiTM)

Cómo funciona AiTM en la práctica

Los ataques de phishing AiTM se sitúan entre el usuario y el servicio real. El atacante:

• Atrae al usuario a una página de login falsa
• Reenvía credenciales al servicio legítimo en tiempo real
• Captura lo que devuelve el servicio (incluidos tokens de sesión)

Por eso «contraseña + OTP» puede seguir fallando. El atacante no necesita robar el OTP para usarlo más tarde. Lo utiliza en el momento.

Qué cambia con passwordless

Passwordless reduce la eficacia de AiTM cuando se implementa como autenticación resistente al phishing, y no solo como «sin campo de contraseña».

Dos cambios importan especialmente:

• No hay secreto reutilizable que teclear: el usuario no introduce una contraseña que pueda capturarse y reutilizarse.
• La prueba criptográfica sustituye a los secretos introducidos por el usuario: en lugar de reenviar contraseña y código, el atacante tendría que conseguir que el usuario complete una operación criptográfica bajo condiciones que el autenticador debería restringir.

El resultado práctico es que muchos flujos de phishing masivo pierden su valor principal: capturar secretos introducidos por usuarios a escala.

Ataque 2: ataques de repetición y robo de tokens

Cómo funciona la repetición

Cuando los atacantes no pueden robar contraseñas de forma fiable, a menudo roban sesiones:

• Cookies de sesión capturadas por malware
• Tokens extraídos de equipos
• Sesiones reutilizadas desde navegadores comprometidos
• Tokens obtenidos tras un primer phishing exitoso

La repetición no se resuelve solo con passwordless, porque apunta a la sesión después de la autenticación.

Qué cambia con passwordless

Passwordless ayuda de dos formas:

• Menos compromisos iniciales exitosos: menos credenciales robadas implica menos «primeras sesiones» que robar.
• Más oportunidades de política y autenticación reforzada: cuando passwordless se despliega a través de una capa de IdP y SSO, puedes exigir autenticación reforzada para sesiones de riesgo y acciones sensibles.

Por eso importan la higiene de sesión y las sesiones de corta duración, especialmente en dispositivos compartidos y no gestionados.

Ataque 3: fatiga de MFA (bombardeo de push) e ingeniería social

Cómo funcionan los ataques de fatiga

Los ataques de fatiga por MFA push explotan un patrón humano: si los usuarios reciben prompts repetidos, algunos acabarán aprobando uno para que la interrupción pare, o aprobarán bajo estrés y confusión.

Qué cambia con passwordless

Passwordless reduce la dependencia de prompts tipo «aprobar/denegar» que se pueden spamear.

Cuando la autenticación se basa en posesión más verificación del usuario (por ejemplo, tocar una llave de seguridad o verificación local), la capacidad del atacante para disparar prompts repetidos a escala se limita, y el ataque se vuelve más visible.

El riesgo restante se desplaza hacia:

• Métodos débiles de autenticación reforzada que siguen usando prompts push
• Rutas de recuperación y helpdesk
• Políticas inconsistentes entre aplicaciones

El nuevo objetivo del atacante: recuperación y excepciones

A medida que passwordless reduce el robo basado en contraseñas, los atacantes se mueven hacia el camino más débil que quede. En muchas empresas, ese camino es la recuperación: enlaces de restablecimiento, overrides del helpdesk y verificación de identidad inconsistente.

Esto no es un motivo para evitar passwordless. Es un motivo para diseñar recuperación y excepciones como controles de seguridad de primer nivel.

Relacionado: Errores comunes al implementar una autenticación passwordless en empresas (y cómo evitarlos)

Qué medir: cómo demostrar reducción de riesgo

Si quieres demostrar que passwordless está reduciendo exposición real, mide métricas que correspondan con los resultados que buscan los atacantes:

• Porcentaje de accesos de alto riesgo que usan métodos resistentes al phishing
• Número de eventos de phishing que derivan en sesión válida (antes y después)
• Volumen de restablecimientos de contraseña y eventos de recuperación (y de intentos de abuso)
• Tasa de excepciones por aplicación y tiempo hasta retirar excepciones
• Incidentes de toma de control de cuentas y tiempo hasta contenerlos
• Sesiones de acceso privilegiado que requieren autenticación reforzada para acciones sensibles

Estas métricas convierten «adopción de passwordless» en «reducción de riesgo».

Dónde encaja la preparación poscuántica (brevemente)

No todas las decisiones de autenticación requieren una conversación poscuántica. Pero en entornos regulados, con credenciales de larga duración y migraciones caras, sí conviene introducirlo de forma explícita.

La idea clave es sencilla: la preparación poscuántica no va solo de elegir un algoritmo nuevo, sino de evitar dependencias rígidas que hagan que un cambio de estándar rompa tu programa de autenticación. En la práctica, esto significa diseñar para la evolución: políticas separadas de la criptografía, ciclos de vida de credenciales preparados para rotación y re-registro, y rutas de recuperación que no se conviertan en el punto más atacable cuando llegue el momento de migrar.

En Secrets Vault ayudamos a equipos que necesitan control auditable y garantía a largo plazo a incorporar esta visión desde el diseño, de forma que el programa passwordless pueda adaptarse conforme cambien los estándares, incluida la criptografía poscuántica, sin introducir excepciones frágiles ni migraciones disruptivas.