FIDO2, passkeys y los autenticadores hardware

Dec 18, 2025 | Categories: Seguridad | Tags: Identidad, MFA, FIDO2

Durante décadas, la seguridad digital se apoyó en un supuesto frágil: que los usuarios podían custodiar secretos de forma consistente en sistemas cada vez más complejos. Contraseñas únicas, largas, rotadas periódicamente y nunca reutilizadas. El problema en esto no fue la falta de reglas, sino la expectativa irreal de cumplimiento humano.

El resultado es conocido y un poco de lo que hablaba en Deja de rotar las contraseñas : reutilización masiva de credenciales, phishing cada vez más sofisticado y mecanismos de “doble factor” que, en la práctica, no resisten un ataque bien ejecutado. Gran parte de la seguridad moderna sigue basada en secretos que pueden ser copiados, interceptados o engañados.

Desde un punto de vista técnico, el problema es estructural. Desde uno filosófico, es aún más simple: si algo puede copiarse sin fricción, no puede considerarse una prueba sólida de identidad.

En los últimos años comenzó a popularizarse el concepto de passkeys   , una forma moderna de autenticación definida dentro del estándar FIDO2/WebAuthn   . Una passkey no es una contraseña mejorada, sino un par de claves criptográficas asimétricas generado para un servicio específico, donde la clave privada permanece protegida en el dispositivo del usuario (hardware dedicado, sistema operativo o autenticador externo) y la clave pública es almacenada por el servicio. La autenticación se realiza mediante firmas criptográficas y validación del contexto, eliminando la necesidad de compartir secretos reutilizables. Este enfoque está estandarizado por la FIDO Alliance y adoptado por los principales sistemas operativos y navegadores modernos.

En este contexto aparecen los autenticadores hardware para almacenar estas passkeys, y en particular las YubiKey que utilizo en mi día a día. No como una solución mágica sino como un cambio de paradigma: pasar de demostrar conocimiento de un secreto a demostrar posesión verificable de un objeto físico, respaldada por criptografía asimétrica y validación del contexto en el que ocurre la autenticación.

Este artículo no pretende evangelizar ni vender dispositivos. La intención es analizar qué problema real resuelven los autenticadores hardware, en qué escenarios aportan seguridad tangible y dónde, simplemente, agregan complejidad innecesaria. Porque la seguridad no se trata de acumular controles, sino de reducir superficies de ataque sin perder control operativo.

¿Qué es un autenticador hardware (y qué no es)?

Un autenticador hardware es un dispositivo físico de autenticación diseñado para demostrar identidad mediante mecanismos criptográficos estándar. No almacena contraseñas de servicios ni actúa como un contenedor genérico de secretos. Su función principal es probar presencia física y posesión de una clave privada que no puede ser extraída del dispositivo.

Desde el punto de vista técnico, un autenticador hardware como la YubiKey implementa varios protocolos abiertos —principalmente FIDO2/WebAuthn, pero también U2F, OTP, PIV y OpenPGP según el modelo— que permiten a un sistema remoto verificar identidad sin necesidad de compartir secretos reutilizables. La clave privada nunca abandona el dispositivo; lo único que viaja es una firma criptográfica generada en respuesta a un desafío específico.

Este detalle es central: no hay un secreto que pueda ser copiado. A diferencia de una contraseña o un código TOTP, no existe información que un atacante pueda interceptar y reutilizar más tarde. La autenticación está ligada tanto al dispositivo físico como al contexto de uso (por ejemplo, el dominio web que solicita la autenticación).

Yubikey Series

Qué es un autenticador hardware

  • Un dispositivo físico que funciona como autenticador basado en criptografía asimétrica.
  • Un mecanismo de prueba de posesión con verificación de presencia física.
  • Un segundo factor fuerte o, en algunos escenarios, el factor principal de autenticación.
  • Una pieza que puede integrarse en flujos modernos de identidad, como Zero Trust o passwordless.

En términos prácticos, un autenticador hardware cambia el foco de la seguridad desde “algo que sabés” hacia “algo que tenés”, reduciendo drásticamente la superficie de ataque asociada al phishing y al robo de credenciales.

Qué no es un autenticador hardware

  • No es un gestor de contraseñas.
  • No es un pendrive ni un almacén de secretos en texto claro.
  • No es una garantía absoluta de seguridad.
  • No reemplaza el diseño correcto de accesos, monitoreo o respuesta a incidentes.

Un autenticador hardware puede fortalecer un sistema mal diseñado, pero no puede corregir decisiones estructuralmente débiles.

Un cambio de modelo, no una mejora incremental

La diferencia más importante que introduce un autenticador hardware no es tecnológica, sino conceptual. Las contraseñas y muchos mecanismos de MFA tradicionales se basan en secretos compartidos. Los autenticadores hardware rompen con ese modelo: la verificación se realiza sin compartir el secreto, y la identidad se valida mediante una prueba criptográfica ligada a un objeto físico específico.

Ese cambio de enfoque es lo que justifica su adopción en entornos donde la identidad es un activo crítico.

Los protocolos importan más que el hardware

Hasta aquí vengo hablando pensando principalmente en YubiKeys (y continuaré hablando de ellas en este y otros artículos del blog, como dije: es el hardware que utilizo). Pero asumirlo como el estándar sería un error conceptual, la seguridad no está en la marca, sino en los protocolos que el dispositivo implementa. YubiKey es relevante porque adopta estándares abiertos y ampliamente soportados, no porque sea un artefacto mágico, y de hecho existen otros dispositivos con igual compatibilidad que mencionaré más adelante.

Desde una perspectiva técnica, el valor de un autenticador hardware está determinado por dos factores:

  1. qué protocolos soporta,
  2. cómo los implementa.

El dispositivo es intercambiable, el protocolo no.

FIDO2 / WebAuthn: el estándar que cambia las reglas

FIDO2, junto con WebAuthn, es hoy el protocolo más relevante en autenticación fuerte. Define un modelo basado en criptografía asimétrica donde:

  • Cada servicio recibe un par de claves único.
  • La clave privada nunca abandona el dispositivo.
  • La autenticación está ligada criptográficamente al dominio que la solicita.
  • Se requiere presencia física (y opcionalmente PIN o biometría).

Esto elimina de raíz clases enteras de ataques como phishing, replay, credential stuffing y robo de bases de contraseñas reutilizables.

Lo importante no es que una YubiKey soporte FIDO2, sino que cualquier autenticador que lo implemente correctamente hereda estas propiedades.

U2F: antiguo, pero aún vigente

U2F es el predecesor de FIDO2. Aunque hoy se lo considera “legacy”, sigue siendo ampliamente soportado y, desde el punto de vista de seguridad, sigue siendo muy superior a TOTP o SMS.

Limitaciones:

  • no soporta passwordless
  • menor flexibilidad
  • menos control de políticas

Aun así, un dispositivo U2F bien implementado sigue siendo una mejora real frente a MFA débiles.

OTP y TOTP: útiles, pero insuficientes

Muchos autenticadores hardware ofrecen generación de códigos OTP o TOTP. Técnicamente funcionan, pero conceptualmente no resuelven el problema de fondo:

  • siguen siendo secretos reutilizables
  • son vulnerables a phishing en tiempo real
  • no validan contexto ni origen

Son un paso intermedio, no un objetivo final. Útiles cuando no hay otra opción (el caso de muchos servicios al día de hoy), pero no comparables con FIDO2.

PIV / OpenPGP: casos más especializados

Algunos dispositivos soportan PIV (certificados X.509 / smartcard) y OpenPGP. Estos modos son muy útiles en contextos específicos: autenticación empresarial tradicional, firma de código, correo cifrado, SSH con claves no exportables, etc.

Son casos de uso bastante más técnicos, no pensados para el usuario promedio, pero en esos entornos con requerimientos técnicos específicos, bien gestionados siguen siendo herramientas sólidas.

YubiKey no está sola: hay varias alternativas

YubiKey es probablemente el dispositivo más conocido, pero no es el único ni el requisito para adoptar autenticación fuerte.

Existen alternativas de diferente porte como:

  • SoloKeys
  • Nitrokey
  • Google Titan
  • Thales SafeNet eToken Fusion

e inclusive autenticadores integrados en hardware (como Secure Enclave en dispositivos Apple o plataformas FIDO integradas), inclusive el chip TPM puede funcionar para esto (Windows Hello utiliza TPM cuando no se tiene un autenticador físico diferente).

Lo cierto es que todas estas opciones pueden ser válidas si implementan correctamente FIDO2/WebAuthn, usan estándares abiertos y tienen soporte estable en los servicios que se usan.

La pregunta correcta entonces no es “¿qué marca compro?”, sino: “¿Qué protocolos necesito, que estén disponibles y bien soportados en mi stack?”

Entonces, ¿por qué FIDO2 es distinto?

La mayoría de los mecanismos de autenticación fallan por la razón que he mencionado: confían en secretos reutilizables. Contraseñas, códigos OTP, TOTP o enlaces mágicos son variantes del mismo patrón. Cambian la forma pero no la naturaleza del problema: si el secreto puede ser capturado o reenviado, puede ser explotado.

FIDO2 rompe con ese modelo. Y lo hace sin añadir otra capa sobre la contraseña, directamente elimina la necesidad de compartir un secreto.

Autenticación basada en desafío, no en secretos

En FIDO2, el flujo es fundamentalmente distinto a los mecanismos mencionados anteriormente:

  1. El servicio genera un desafío criptográfico único.
  2. El autenticador firma ese desafío con una clave privada almacenada en hardware.
  3. El servicio valida la firma usando la clave pública registrada previamente.

Aquí un diagrama que ilustra este flujo de autenticación:

UUssuuaarriioTPoIoIncNiac/iAauBtiseoenmsteiitócrnaídao(rWe/NbNaAavuveteghganaddoASCgAEorPohesnrIlatsv)il(eícl)raieA(FcpttnueioriaVcagtjrnioseoee.mvnsrncnacaeiAh+tYld(rfccaiucaaftilclRcbhviicaelPaiaeroavsedKlmneonIoelafgDrye)ipOe)nrúKgmb(ealRieclaSySeiernrvgviicPciaioroty)

Entonces no hay información reutilizable, no hay código válido por cierto tiempo, ni nada que interceptar. Cada autenticación es un evento único, no una repetición de un secreto preexistente.

El dominio importa (y esto detiene el phishing)

Uno de los aspectos clave de FIDO2 es el binding al origen. El autenticador valida el dominio que solicita la autenticación y solo responde si coincide con el dominio para el cual se generó la clave.

Esto tiene una consecuencia directa y práctica: un sitio falso puede verse idéntico, puede usar HTTPS y puede tener un certificado válido, pero no puede obtener una firma válida, porque no controla el dominio legítimo.

En otras palabras: el phishing deja de ser un problema de “educación del usuario” y herramientas para bloquearlo y pasa a ser un problema técnico del atacante. Y eso es exactamente lo que debe ser. Por eso hablamos de FIDO2 como un mecanismo de autenticación resistente a phishing.

Presencia física verificable

FIDO2 requiere una acción física del usuario: tocar el dispositivo, ingresar un PIN o usar biometría (dependiendo del autenticador). Esto introduce una prueba de presencia que no puede automatizarse ni simularse remotamente. El usuario participa activamente del evento de autenticación.

Claves únicas por servicio

Cada servicio recibe un par de claves distinto. Esto elimina otro problema histórico: el impacto en cascada en el que se basan ataques como credential stuffing. Si un proveedor es comprometido no hay credenciales reutilizables ni forma de moverse lateralmente a otros servicios. De esta forma el compromiso queda contenido por diseño.

A continuación un diagrama de cómo se asocia un autenticador a un servicio:

UUssuuaarriiooITnoiccaiaAurteegnitsitcraod(oWreNbNaAavuveteghganaddoASCcPEorPohrunrIlaebv)ilalícltiaieeA(Gc(Psctn(ueelpraccauag)tjnarilKllssee.eviveeaaoucnrevayvAvcah+tYas/ddeleiraiupae+mailRcbpúulpapdolPaianbnAúcúaedKri)uhtbebnIoecnwtlnlagDrydoceiaile)eascctaa(aRteiloSynSeiernrvgviicPciaioroty)

FIDO2 como base para passwordless

Todo lo anterior permite algo que años atrás era impracticable a escala: eliminar completamente la contraseña. No hablamos de un ideal teórico, sino de una implementación real que grandes proveedores como Microsoft están adoptando e impulsando. Passwordless es una consecuencia natural de un modelo de identidad mejor diseñado.

Una reflexión filosófica

Durante años se intentó compensar las debilidades humanas con más reglas, más complejidad y más advertencias. FIDO2 propone lo contrario: aceptar las limitaciones humanas y diseñar el sistema en torno a ellas.

No se trata de confiar en que el usuario no caerá en un engaño. Se trata de construir un sistema donde caer en un engaño no sea suficiente para comprometer la identidad. A mi parecer, una corrección conceptual importante y necesaria.

Usos reales: dónde una autenticador hardware aporta seguridad tangible

No todos los sistemas se benefician por igual de un autenticador hardware. En algunos casos el impacto es marginal, en otros es un gran paso en la seguridad de la identidad. Como entenderás, la diferencia no está en la tecnología, sino en qué riesgo se está intentando reducir.

No voy a enumerar todo lo que se puede hacer con estos dispositivos, sino algunas cosas que vale la pena hacer. En futuros artículos espero desarrollar estos y otros casos de uso.

Protección de cuentas críticas

Las cuentas que permiten recuperar otras cuentas —principalmente el correo electrónico y el gestor de contraseñas— son el punto de partida lógico.

Aplicar FIDO2 en estos servicios tiene un efecto inmediato: el phishing deja de ser viable, el robo de sesión se dificulta drásticamente y el impacto de un compromiso se reduce.

En este contexto, con una buena implementación, un autenticador hardware no actúa como “segundo factor”, sino como ancla de identidad. Si el atacante no tiene el dispositivo físico, el acceso simplemente no ocurre.

Control de acceso a repositorios y código

Plataformas como GitHub o GitLab concentran un volumen creciente de activos críticos: código, pipelines, secretos, tokens y accesos a infraestructura.

El uso de FIDO2 o claves no exportables para iniciar sesión, firmar commits o acceder a runners o APIs reduce riesgos concretos de suplantación de identidad, ataques a la cadena de suministro o introducción de código malicioso con autoría legítima aparente.

Acceso a infraestructura y sistemas administrativos

En entornos de servidores, cloud o redes, la autenticación fuerte tiene un retorno claro.

Algunos casos típicos pueden ser:

  • SSH con claves FIDO2 no exportables
  • bastiones de acceso
  • paneles de control administrativos
  • proveedores de VPS o DNS

La diferencia frente a claves tradicionales es fundamental: el secreto no puede copiarse, aunque el sistema desde el que se accede esté comprometido.

Linux y control local del sistema

Este es un caso que he utilizado y explorado particularmente, pues en sistemas GNU/Linux, un autenticador puede integrarse más allá del navegador:

  • sudo con verificación de presencia
  • login local mediante PAM
  • desbloqueo de volúmenes cifrados (LUKS)
  • firma GPG desde hardware

Estos usos son especialmente relevantes en laptops, equipos de trabajo móviles o contextos donde el control físico no es absoluto, permiten elevar el costo real de un compromiso local. Vale aclarar que varios de estos casos tienen su equivalente en sistemas Windows con Windows Hello y herramientas de terceros.

Cuando no aporta valor real

Creo que saber en qué casos no es relevante adoptar un autenticador hardware es tan importante como saber dónde sí.

En general, no se justifica adoptar este tipo de autenticación en:

  • sistemas de bajo impacto
  • accesos efímeros sin privilegios
  • entornos donde no hay soporte adecuado de protocolos
  • reemplazo de controles básicos mal implementados

Agregar hardware sin un objetivo claro suele introducir fricción sin mejorar la seguridad.

Una regla práctica

Si una cuenta permite:

  • recuperar otras cuentas
  • ejecutar código
  • modificar infraestructura
  • acceder a datos sensibles

entonces justifica autenticación fuerte basada en hardware. Si no, probablemente no.

Estos dispositivos y las passkey no están pensadas para usarse en todas partes, sino en los puntos donde la identidad es crítica. Ahí es donde el cambio de modelo que introduce FIDO2 se traduce en una mejora de seguridad concreta y medible.

Errores comunes y malas decisiones

La adopción de autenticadores hardware suele fallar no por limitaciones técnicas, sino por decisiones mal entendidas. En muchos casos, el autenticador termina siendo un amuleto de seguridad: está presente, pero no cambia el modelo de riesgo.

Usar una sola llave

Este probablemente sea el error más común. Un dispositivo como una YubiKey es un objeto físico (y bastante pequeño). Los objetos físicos se pierden, se rompen o quedan inaccesibles. Usar una sola llave sin un método alternativo de recuperación es una receta para el bloqueo permanente.

Buenas prácticas mínimas:

  • al menos dos autenticadores registrados
  • uno de uso diario
  • uno de respaldo, almacenado offline

Reemplazar completamente la passphrase sin backup

Eliminar contraseñas sin un plan de recuperación es ir de passwordless a irrecuperable.

En servicios críticos o cifrado local es imortante mantener un método alternativo (passphrase, recovery key), documentar el proceso de recuperación y probarlo antes de necesitarlo.

Usar OTP “porque es lo que hay”

Generar códigos OTP desde una YubiKey es mejor que SMS, pero no cambia el modelo de amenaza. El código sigue siendo un secreto reutilizable, susceptible a phishing en tiempo real.

Este error suele aparecer cuando el servicio soporta FIDO2 pero no se habilita, o se prioriza compatibilidad sobre seguridad. Pero si el protocolo no elimina la clase de ataque, el beneficio es limitado.

Creer que FIDO2 reemplaza otros controles

FIDO2 protege la identidad, no el sistema completo.

No reemplaza:

  • monitoreo
  • detección de compromisos
  • gestión de privilegios
  • separación de funciones
  • respuesta a incidentes

Un atacante sigue siendo efectivo si obtiene privilegios indebidos por otros medios. Es importante entender que la autenticación fuerte es una base, no una defensa total.

No entender qué protocolo se está usando

Muchas implementaciones fallan por desconocimiento, creer que MFA automáticamente implica resistencia al phishing, no distinguir entre diferentes protocolos y asumir que todos los flujos son equivalentes es un error.

El resultado es una falsa sensación de seguridad basada en etiquetas, pero no en propiedades reales del protocolo.

No proteger el canal de recuperación

El acceso más débil suele ser el mecanismo de recuperación de cuenta.

De poco sirve usar FIDO2 si:

  • el recovery sigue siendo email + SMS
  • se permite downgrade a MFA débil
  • el soporte puede resetear accesos sin verificación fuerte

La seguridad se debe evaluar por el camino más fácil, no por el más robusto.

Introducir fricción sin un objetivo claro

En un mundo ideal podríamos adoptar autenticación fuerte en todos los sistemas, pero en el mundo real agregarla a sistemas de bajo impacto o sin privilegios reales suele generar rechazo y abandono.

La autenticación fuerte debe aplicarse donde el impacto de un compromiso es alto, la identidad es un activo crítico y la fricción está justificada.

Conclusión

El error más común al hablar de seguridad es pensarla como una suma de controles. Más factores, más reglas, más advertencias. En la práctica, esto suele producir sistemas frágiles, difíciles de operar y fáciles de eludir por el camino menos pensado.

Un modelo mental más útil parte de otra premisa: la identidad es un sistema, no un dato.

Las contraseñas fallan no porque sean cortas o reutilizadas, sino porque son secretos copiables. No importa cuántas veces se roten o cuántos factores se agreguen alrededor; mientras el modelo dependa de algo que puede ser interceptado y reutilizado, el problema persiste.

FIDO2 introduce una corrección conceptual simple pero profunda: la identidad no se demuestra compartiendo un secreto, sino probando posesión y contexto mediante criptografía. No se confía en que el usuario recuerde mejor, sino en propiedades matemáticas y en la imposibilidad práctica de copiar un objeto físico o almacenado en un chip criptográficamente robusto.

Los autenticadores hardware no son una solución universal ni un requisito para todos los sistemas. Su valor aparece cuando la identidad pasa a ser un activo crítico.

Usadas correctamente, permiten:

  • eliminar el phishing como vector efectivo
  • reducir el impacto de compromisos parciales
  • simplificar modelos de acceso complejos
  • habilitar passwordless sin perder control

Usadas incorrectamente, se convierten en una capa más de fricción, sin beneficios proporcionales.

La diferencia no está en el dispositivo, sino en cómo se piensa el problema. Adoptar FIDO2 es una decisión de arquitectura: aceptar que los sistemas deben diseñarse en función de las limitaciones humanas, no en contra de ellas. En ese marco, los autenticadores hardware no son un fin, sino una herramienta bien definida para un problema concreto. Y como toda buena herramienta, su valor no está en poseerla, sino en saber exactamente cuándo y por qué usarla.

Referencias