FIDO2 y passkeys: beneficios, opciones y cómo evaluarlos

La mayoría de los kits de phishing tienen algo en común: funcionan porque tus usuarios tienen un secreto que entregar. Una contraseña, un código de un solo uso, una notificación push que pueden aprobar bajo presión: todo ello es conocimiento compartido que se puede retransmitir, reutilizar o arrancarle a una persona por agotamiento. FIDO2 rompe ese modelo. Esta es una guía de trabajo sobre qué son realmente FIDO2 y las passkeys, las opciones entre las que tienes que elegir y un checklist concreto para evaluarlas antes de desplegarlas.

Para tomar estas decisiones de forma práctica antes de desplegar nada, trabaja con el Passkey Lab de PlayCISO.

Qué son realmente FIDO2, WebAuthn y CTAP

«FIDO2» es un paraguas para dos especificaciones que funcionan juntas. WebAuthn es la API de navegador del W3C a la que llama un sitio web (la relying party, o RP) para registrar y autenticar un autenticador. CTAP (Client to Authenticator Protocol, de la FIDO Alliance) es el protocolo que permite que un autenticador externo (una llave de seguridad por USB, NFC o Bluetooth) hable con el navegador o el sistema operativo. Una passkey es simplemente una credencial FIDO2/WebAuthn usada como factor de inicio de sesión, comercializada con un nombre más amable.

El mecanismo es criptografía de clave pública corriente, aplicada con cuidado. Cuando un usuario se registra, el autenticador genera un par de claves nuevo limitado a ese único sitio web. La clave privada nunca sale del hardware del autenticador; solo la clave pública se envía a la RP y se guarda asociada a la cuenta. Al iniciar sesión, el servidor envía un desafío aleatorio, el autenticador lo firma con la clave privada y el servidor verifica la firma con la clave pública guardada. No hay ningún secreto compartido en tránsito, ni almacenado en el servidor, ni en ningún lugar que un volcado de la base de datos pueda exponer.

Por qué es resistente al phishing, y el OTP y el push no

La propiedad que más importa es la vinculación al origen. El navegador y el autenticador ligan cada credencial al origen exacto que la creó: esquema, host y puerto. Una firma producida para login.yourbank.com no sirve criptográficamente de nada a login-yourbank.evil.com, y el autenticador simplemente se negará a producir una para el origen equivocado. No se puede engañar al usuario para que la «entregue», porque no hay nada entregable y el navegador impone el destino por él.

Compáralo con los factores heredados:

• OTP (TOTP/SMS): un secreto compartido de vida corta que el usuario lee y escribe. Un proxy de phishing simplemente lo retransmite al sitio real en tiempo real. El código es válido dondequiera que se introduzca.
• Aprobación push: vulnerable a la fatiga de MFA (bombardea a alguien a las 2 de la madrugada y un toque lo resuelve) y a la retransmisión en tiempo real de la solicitud.
• FIDO2: no hay código que leer, ni secreto que escribir, ni solicitud que aprobar contra el sitio equivocado. La firma está ligada al origen, así que un atacante intermedio no tiene nada que reenviar.

Las ventajas frente al OTP y el push se derivan directamente: resistencia real al phishing en lugar de simple fricción, ningún secreto compartido que robar o filtrar, ninguna ingeniería social basada en el agotamiento y una experiencia de usuario claramente mejor: un toque o una mirada en lugar de un código copiado de otro dispositivo.

Opción 1: autenticadores de plataforma frente a llaves de seguridad itinerantes

Un autenticador de plataforma está integrado en el dispositivo: Windows Hello, Face ID y Touch ID en los dispositivos de Apple, y el autenticador biométrico o de bloqueo de pantalla de Android. Es cómodo, siempre está disponible y se desbloquea con un dato biométrico o un PIN. Su debilidad es que está ligado a ese único dispositivo: si lo pierdes o lo cambias, la credencial desaparece salvo que esté sincronizada.

Un autenticador itinerante es una llave de seguridad de hardware independiente (YubiKey, Feitian, Google Titan y similares) que se conecta por USB, NFC o BLE. Se puede llevar de una máquina a otra, es difícil de clonar y se puede entregar e inventariar como cualquier otro activo. También es un objeto más que comprar, distribuir y reponer cuando se pierde. Para los colectivos de alta garantía, la llave itinerante suele ser el factor principal adecuado; para el conjunto de la plantilla, los autenticadores de plataforma impulsan la adopción porque no hay nada que llevar.

Opción 2: passkeys ligadas al dispositivo frente a sincronizadas

Esta es la distinción que más a menudo confunde a los compradores empresariales. La clave privada de una credencial ligada al dispositivo nunca sale del autenticador que la creó: el comportamiento clásico de una llave de hardware. Una passkey sincronizada se copia, cifrada de extremo a extremo, en un llavero en la nube (iCloud Keychain de Apple, el Gestor de contraseñas de Google o un gestor de contraseñas de terceros) para que aparezca automáticamente en los demás dispositivos del usuario.

Las passkeys sincronizadas son una enorme mejora de usabilidad y la razón por la que las passkeys se han generalizado: los usuarios ya no se quedan bloqueados al cambiar de teléfono. Pero la contrapartida es real. La garantía de una passkey sincronizada es tan fuerte como la cuenta en la nube y su flujo de recuperación, y ese flujo de recuperación puede, si no tienes cuidado, convertirse en la ruta vulnerable al phishing que intentabas eliminar. La sincronización también significa que la credencial se puede compartir (AirDrop, una bóveda de contraseñas compartida), lo que choca con el principio de «una identidad, una llave». Para tus cuentas de mayor riesgo, en general quieres llaves ligadas al dispositivo en las que puedas demostrar que la clave vive en hardware certificado y no se puede copiar.

Opción 3: atestación y AAGUID

La atestación es una declaración firmada, producida durante el registro, sobre la marca y las propiedades de seguridad del autenticador. El AAGUID (Authenticator Attestation GUID) es un identificador de 128 bits del modelo de autenticador. Juntos permiten a una RP responder «¿qué tipo de autenticador es este y me fío de él?»; por ejemplo, permitir solo llaves de hardware certificadas de una lista de fabricantes aprobados para las cuentas privilegiadas y bloquear los autenticadores desconocidos o de software. Ten en cuenta que muchos autenticadores de plataforma y passkeys sincronizadas no devuelven una atestación útil (o devuelven una que preserva la privacidad), así que una política de restricción por atestación y AAGUID se convierte en la práctica en una política de llaves de hardware. Decídelo de forma deliberada.

Opción 4: credenciales residentes (descubribles) frente a no residentes

Una credencial residente o descubrible guarda en el autenticador el estado suficiente para identificar al usuario sin que tenga que escribir antes un nombre de usuario: es lo que permite un inicio de sesión real sin nombre de usuario y sin contraseña. Una credencial no residente no guarda nada en el autenticador; la RP debe aportar el ID de la credencial (normalmente después de que el usuario introduzca un nombre de usuario) y el autenticador se limita a firmar. Las credenciales descubribles ofrecen la mejor experiencia de usuario y son necesarias para los flujos de tipo passkey, pero consumen las limitadas ranuras de almacenamiento de las llaves de hardware y permiten que cualquiera con la llave desbloqueada enumere las cuentas, así que combínalas con un PIN o un dato biométrico (verificación del usuario).

Criterios de evaluación: cómo elegir y desplegar

Usa esto como checklist de decisión al evaluar fabricantes, proveedores de identidad y tu propio plan de despliegue:

• Atestación y política de restricción de llaves: ¿puedes exigir atestación y permitir solo AAGUID concretos para los roles privilegiados? Confirma que tu proveedor de identidad la aplica de verdad y no se limita a recogerla.
• Ligadas al dispositivo o sincronizadas, según el colectivo: exige llaves de hardware certificadas y ligadas al dispositivo para administradores, finanzas y otras cuentas de alta garantía; permite passkeys sincronizadas para el resto de la plantilla para impulsar la adopción.
• Nivel de certificación (FIDO L1/L2): exige al menos FIDO Certified L1; prefiere L2 (resistencia a la manipulación del hardware) para las llaves que protegen accesos privilegiados. Relaciona la certificación con los AAGUID que permites.
• Estrategia de recuperación de cuentas: aquí es donde fracasan la mayoría de los programas de passkeys. No dejes nunca que la recuperación recurra al SMS, a enlaces mágicos por correo o a una pregunta de seguridad: eso recrea una ruta vulnerable al phishing que rodea tu factor resistente al phishing. Registra al menos dos autenticadores por usuario o usa una recuperación gestionada por la empresa (service desk con verificación de identidad o una llave de respaldo guardada de forma segura).
• Soporte de la RP y del proveedor de identidad: verifica el soporte de WebAuthn en tu proveedor de identidad, en las aplicaciones SaaS críticas y en la VPN. Comprueba si la federación (SSO) permite que un único inicio de sesión fuerte cubra las aplicaciones posteriores, y dónde las carencias obligan a un respaldo más débil.
• Registro y ciclo de vida: planifica un registro supervisado (para vincular la llave a una identidad verificada y no a la de un atacante), el alta por autoservicio de una segunda llave y la baja inmediata cuando alguien deja la organización. Controla las llaves como activos inventariados.
• Residentes o no residentes, y verificación del usuario: exige verificación del usuario (PIN o dato biométrico) para que una llave robada no sea por sí sola una credencial; elige credenciales descubribles donde importe la experiencia sin nombre de usuario.
• Por dónde empezar: empieza por las cuentas que más quiere un atacante (administradores de dominio y de la nube, TI, finanzas, directivos), después los equipos de alto riesgo y, por último, el conjunto de la plantilla. Un factor resistente al phishing en 200 administradores vale más que un factor débil en todo el mundo.

Un orden de despliegue pragmático

No intentes llegar al 100 % de cobertura en un solo programa. Demuestra la mecánica en tus cuentas de mayor valor con llaves de hardware ligadas al dispositivo y una recuperación gestionada por la empresa, elimina por completo sus respaldos vulnerables al phishing y después extiende las passkeys sincronizadas al resto de la población donde el riesgo de recuperación sea aceptable y el beneficio de adopción sea mayor. Mide el éxito no por el porcentaje de registro, sino por cuántas cuentas siguen teniendo un factor vulnerable al phishing que podrías eliminar.