defensiva
passkey
contraseñas
FIDO2

Passkey vs contraseña: cuál es más segura en 2026

Passkey vs contraseña en 2026: veredicto, cómo cae cada credencial ante phishing AiTM, stuffing, brechas y keyloggers, y lo que la passkey no resuelve.

Equipo de Secra Solutions6 de julio de 2026Actualizado el 3 de septiembre de 202611 min de lecturaCómo elaboramos el contenido

En el debate passkey vs contraseña la conclusión técnica es clara: la passkey elimina de raíz las cuatro formas de robo de credenciales que hunden a la contraseña (phishing, credential stuffing, brechas con reutilización y keyloggers), a cambio de introducir un problema nuevo, la recuperación de cuenta. No es una mejora marginal ni una moda de fabricantes: es un cambio de modelo criptográfico, de un secreto compartido que viaja a una clave privada que nunca sale del dispositivo. Esta guía compara ambos enfoques cara a cara: qué ataque hunde a cada credencial, qué flancos deja abiertos la passkey y qué decisiones marcan la migración en una empresa real durante 2026. Si lo que buscas es la definición, el funcionamiento paso a paso y los tipos de passkey, empieza por qué es una passkey.

Veredicto en 30 segundos

CriterioContraseñaPasskey
Resistencia a phishingNula: el usuario puede teclearla en un dominio falsoAlta: la clave se vincula al origen y no se libera fuera de él
Exposición en brechasAlta: el hash reside en el servidor y se craquea offlineBaja: el servidor solo guarda una clave pública inútil para el atacante
Experiencia de usuarioMedia: hay que recordarla y teclearlaAlta: desbloqueo biométrico o PIN local en un gesto
RecuperaciónSencilla pero débil (email, SMS)Compleja: depende del ecosistema y del respaldo
Vinculación al dispositivoNinguna: viaja a cualquier equipoFuerte: clave privada en el authenticator, sincronizada o no

La lectura rápida: en las amenazas que dominan las estadísticas de account takeover, la passkey gana con claridad. Donde la contraseña sigue siendo más simple es en la recuperación, y ahí es donde se juega la migración.

Cómo funciona cada modelo

La diferencia no está en la longitud ni en la complejidad de lo que teclea el usuario, sino en dónde vive el secreto y quién puede reproducirlo.

La contraseña: un secreto compartido

Una contraseña es un secreto compartido entre dos partes. El usuario elige una cadena, el servidor guarda una versión derivada (idealmente un hash con sal usando Argon2id, scrypt o bcrypt, en el orden de preferencia que fija la guía de almacenamiento de contraseñas de OWASP) y, en cada inicio de sesión, el usuario vuelve a transmitir el secreto sobre TLS para que el servidor lo rehashee y compare.

El problema estructural es que ese secreto existe, como mínimo, en dos sitios: la memoria (o el gestor) del usuario y la base de datos del servidor. Cualquiera que lo intercepte lo puede reproducir. Una página de phishing lo captura al teclearlo, un keylogger lo registra, y una brecha de la base de datos entrega los hashes para craqueo offline. La contraseña es replayable por diseño: quien la conoce, entra.

La passkey: criptografía de clave pública (FIDO2/WebAuthn)

Una passkey es una implementación de FIDO2, el estándar que combina WebAuthn (la API del navegador y del servidor, especificada por el W3C) y CTAP2 (el protocolo entre el cliente y el authenticator, definido por la FIDO Alliance). Las dos ceremonias del protocolo, el registro y la autenticación, y los tipos de authenticator los explicamos paso a paso en cómo funciona una passkey; aquí importa solo lo que cambia frente a la contraseña.

Lo que cambia es dónde vive el secreto. El authenticator genera un par de claves asimétricas (típicamente ECDSA sobre P-256, ES256) cuya clave privada nunca sale del enclave seguro, el TPM o la llave física. El servidor solo almacena la clave pública, un identificador de credencial y el AAGUID del modelo de authenticator. En cada login firma un reto aleatorio tras una verificación local (biometría o PIN, que no se transmite), y la firma queda vinculada al RP ID, es decir, al origen: una passkey registrada para accounts.ejemplo.com no firmará un reto presentado desde accounts-ejemplo.evil.com. No hay secreto compartido, no hay token reproducible y no queda nada valioso que robar en el servidor. La base criptográfica es la misma que sostiene los certificados digitales, explicada en qué es PKI.

Modelo de amenaza cara a cara

Aquí es donde la comparación deja de ser teórica. Estas son las cuatro amenazas que concentran la mayoría de compromisos de credenciales y cómo responde cada modelo.

Phishing y ataques adversary-in-the-middle (ATT&CK T1557). La contraseña pierde: el usuario la teclea en una réplica del portal legítimo y el atacante la reenvía. Frente a proxies de phishing modernos como Evilginx, que roban también el token de sesión, ni siquiera el MFA por OTP salva. La passkey gana: la vinculación al origen hace que el navegador se niegue a usar la credencial en el dominio equivocado, y la firma nunca es válida para el sitio del atacante. Es el control que neutraliza el AiTM de forma estructural, no probabilística, y por eso la ficha de CISA sobre MFA resistente a phishing sitúa a FIDO/WebAuthn por encima de cualquier MFA basada en códigos o notificaciones push. Los distintos vectores están desglosados en tipos de phishing.

Credential stuffing y reutilización (ATT&CK T1110.004). La contraseña pierde: como el usuario repite la misma cadena en varios servicios, un par filtrado en una brecha abre puertas en otras plataformas. La passkey gana: cada relación genera un par de claves único e independiente, no hay nada que reutilizar ni ninguna contraseña que probar en masa. Este ataque, detallado en qué es credential stuffing, simplemente se queda sin combustible.

Brechas de base de datos. La contraseña pierde: aunque los hashes estén bien salados, se craquean offline con GPU y diccionarios, sobre todo las cadenas débiles. La passkey gana: lo único que el atacante extrae del servidor es una clave pública, matemáticamente inservible para suplantar al usuario.

Keyloggers e infostealers (ATT&CK T1056.001). La contraseña pierde: se captura en la pulsación o directamente del almacén del navegador. La passkey gana en el caso device-bound, porque no se teclea nada y la clave privada no es exportable. Con un matiz honesto: las passkeys sincronizadas se guardan en un llavero en la nube, así que su seguridad depende también de la robustez de esa cuenta.

Lo que la passkey no resuelve

Ser riguroso obliga a nombrar los flancos que la passkey introduce o no cierra:

  • Pérdida de dispositivo y recuperación. Si la passkey está vinculada al dispositivo y pierdes la llave física, necesitas un authenticator de respaldo. Si está sincronizada, la recuperación depende de tu cuenta de iCloud o de Google, que se convierte en el nuevo eslabón más débil.
  • Aplicaciones y protocolos legacy. SSH, VPN antiguas, sistemas sin soporte WebAuthn o algunas apps nativas siguen necesitando alternativas. La cobertura no es universal en 2026.
  • Degradación por el fallback. Si mantienes la contraseña como método de reserva, el atacante ataca ese camino (la recuperación de cuenta o el "usar contraseña en su lugar"). La resistencia al phishing solo es tan fuerte como el factor más débil que sigas permitiendo.
  • Portabilidad entre ecosistemas. Las passkeys sincronizan dentro de un ecosistema. Moverlas entre Apple, Google y Microsoft mejora con las especificaciones Credential Exchange de la FIDO Alliance (CXP y CXF), pero todavía no es transparente.

La realidad de la migración empresarial en 2026

Ninguna organización pasa de contraseña a passkey de un día para otro. El estado realista es híbrido y conviene diseñarlo con criterio. La elección entre passkeys sincronizadas para el grueso de la plantilla y device-bound para cuentas privilegiadas, con sus niveles AAL según NIST SP 800-63B, la desarrollamos en la sección sincronizada frente a device-bound de qué es una passkey; lo que sigue son las decisiones de política que determinan si la comparación se traduce en una reducción real del riesgo.

Passkey-first con fallback a contraseña

El patrón que funciona en 2026 es passkey-first: se ofrece la passkey como método por defecto y se conserva un fallback controlado durante la transición. Las decisiones que marcan la diferencia:

  • Eliminar el OTP por SMS cuanto antes (vulnerable a SIM swap) y priorizar la passkey sobre cualquier segundo factor tecleado.
  • Endurecer la recuperación de cuenta, porque pasa a ser el objetivo real del atacante. El help desk que restablece credenciales por teléfono es un objetivo habitual de la ingeniería social precisamente porque salta por encima de la passkey.
  • Aplicar políticas de fuerza de autenticación en el IdP (authentication strengths en Microsoft Entra ID, Okta FastPass, Google Workspace, Ping) para exigir passkey en las aplicaciones sensibles vía acceso condicional, y gobernar los authenticators device-bound con enterprise attestation y listas de AAGUID permitidos, de modo que solo los modelos aprobados puedan registrarse para los mandatos de MFA resistente al phishing.
  • Monitorizar los intentos de degradación al método más débil como señal de ataque.

Esta lógica encaja de lleno con el principio de identidad como perímetro que desarrollamos en qué es Zero Trust y con el stack descrito en qué es IAM. La passkey no sustituye a una estrategia de identidad: es su capa de autenticación más fuerte.

Preguntas frecuentes

¿Son las passkeys más seguras que las contraseñas?

Sí, de forma inequívoca frente a las cuatro amenazas dominantes: phishing, credential stuffing, brechas con reutilización y keyloggers. La contraseña es un secreto reproducible; la passkey es una firma criptográfica no reproducible y vinculada al origen. La única dimensión donde la contraseña es más simple es la recuperación, y por eso ese flujo debe diseñarse con especial cuidado al migrar.

¿Se puede hacer phishing a una passkey?

La aserción en sí no se puede phishear: la vinculación al origen impide que un proxy adversary-in-the-middle reutilice la firma, porque queda ligada al dominio del atacante. Lo que sigue siendo atacable es el entorno alrededor: el método de reserva, la recuperación de cuenta o la ingeniería social contra el help desk. El phishing no desaparece, se desplaza hacia el eslabón más débil que dejes habilitado.

¿Las passkeys reemplazan a las contraseñas?

La dirección del sector apunta a que sí a medio plazo, pero durante años convivirán ambos modelos. Los fallbacks, las aplicaciones legacy sin WebAuthn y los flujos de recuperación mantendrán la contraseña presente en las organizaciones. Una cuenta ya migrada a passkey deja de ser vulnerable a los ataques de reutilización, aunque el sistema en su conjunto todavía dependa de cómo gestiones lo que queda por detrás.

¿Es una passkey más segura que una contraseña con MFA por código?

Sí, y la diferencia está en el phishing. Una contraseña con OTP por SMS, TOTP o notificación push sigue siendo capturable por un proxy adversary-in-the-middle, que reenvía el código en tiempo real y se queda con la sesión. La passkey no firma para un origen distinto del registrado, así que ese mismo proxy no obtiene nada. Por eso CISA distingue entre MFA a secas y MFA resistente a phishing, y reserva la segunda categoría para FIDO/WebAuthn y la autenticación basada en certificados.

¿Qué pasa con la recuperación si pierdo el dispositivo?

Ese es el flanco que la comparación no puede ignorar: la contraseña se recupera con un correo, la passkey exige haber previsto un segundo authenticator o una cuenta de nube bien protegida. Los detalles por tipo de passkey y las buenas prácticas de doble registro están en la guía qué es una passkey.

Recursos relacionados

  • Qué es una passkey: definición, funcionamiento paso a paso y tipos (plataforma, hardware, sincronizada, device-bound).
  • Qué es credential stuffing: el ataque que la passkey deja sin combustible al eliminar el secreto reutilizable.
  • Qué es IAM: el stack de identidad donde encaja la autenticación sin contraseña.
  • Tipos de phishing: los vectores que la vinculación al origen neutraliza de raíz.
  • Cómo evitar el phishing: controles complementarios para el factor humano y los flujos de reserva.
  • Qué es PKI: la base criptográfica de clave pública sobre la que se apoyan FIDO2 y WebAuthn.

Passkeys y contraseñas con Secra

La forma más honesta de cerrar esta comparación es probarla: en los ejercicios de Red Team en los que Secra valida una migración a passkeys, el objetivo no es la passkey en sí, sino el "usar contraseña en su lugar", el flujo de recuperación y el service desk. Si cualquiera de esos tres caminos acepta un SMS, un correo de restablecimiento o una llamada sin verificación reforzada, la organización sigue siendo vulnerable a phishing aunque el 100 % de la plantilla tenga passkey registrada. Si quieres someter tu transición a esa prueba, puedes revisar los servicios de ciberseguridad gestionada o escribirnos desde contacto.

Sobre el autor

Equipo de Secra Solutions

Ethical hackers certificados OSCP, OSEP, OSWE, CRTO, CRTL y CARTE, con más de 7 años de experiencia en ciberseguridad ofensiva. Autores de los CVE-2025-40652 y CVE-2023-3512.

Compartir artículo

👋¡Hola! ¿Tienes alguna duda? Escríbenos, respondemos en minutos.

Abrir WhatsApp →