Introducción

En 2026, el panorama de la ciberseguridad continúa cambiando rápidamente, y los métodos de autenticación tradicionales basados en contraseñas se vuelven cada vez más vulnerables e ineficaces. El phishing, la interceptación de credenciales, los ataques de fuerza bruta y el robo de contraseñas siguen siendo los principales vectores de ataque, lo que provoca pérdidas multimillonarias y la pérdida de confianza. En este contexto, la tecnología WebAuthn, conocida como Passkeys, deja de ser una solución de nicho y se convierte en un estándar críticamente importante para garantizar un acceso seguro y conveniente a los recursos digitales.

Este artículo está dedicado a la implementación práctica de WebAuthn (Passkeys) para proteger el acceso a servidores basados en Linux y aplicaciones web. Analizaremos por qué este tema es tan importante ahora, en 2026, qué problemas específicos resuelve y para quién está destinada esta guía detallada. En un entorno donde la mayoría de las grandes empresas tecnológicas, como Google, Apple, Microsoft, ya soportan y promueven activamente las Passkeys, ignorar esta tecnología significa un retraso consciente en el ámbito de la seguridad.

¿Por qué es importante este tema en 2026?

Para 2026, el concepto de "Passkeys" (claves de acceso), construido sobre el estándar WebAuthn, ha alcanzado la madurez y el soporte generalizado. Muchos sistemas operativos (Windows, macOS, Android, iOS) y navegadores web (Chrome, Firefox, Safari, Edge) ofrecen integración nativa, permitiendo a los usuarios crear y usar credenciales criptográficamente fuertes, sincronizadas entre dispositivos sin necesidad de recordar o introducir contraseñas. Esto no es solo una mejora de la 2FA; es la eliminación completa de las contraseñas, lo que representa un paso revolucionario en la lucha contra los tipos más comunes de ciberataques.

• Escalada de ataques de phishing: El phishing se ha vuelto tan sofisticado que incluso los usuarios experimentados pueden ser víctimas. Las Passkeys son inherentemente resistentes al phishing, ya que la autenticación está vinculada a un dominio específico (Origin) y no puede ser engañada por un sitio falso.
• Requisitos regulatorios: Muchas normativas nuevas y actualizadas (por ejemplo, NIS2 en Europa, así como estándares de la industria) exigen cada vez más el uso de métodos de autenticación resistentes al phishing. Las empresas que no implementen tales soluciones corren el riesgo de enfrentar multas significativas y pérdidas de reputación.
• Cansancio de contraseñas y 2FA: Los usuarios están cansados de las contraseñas complejas, la necesidad de cambiarlas regularmente y la inconveniencia de los métodos tradicionales de 2FA (SMS, TOTP), que también pueden ser comprometidos. Las Passkeys ofrecen una experiencia fluida y segura.
• Desarrollo del ecosistema: En 2026, están disponibles bibliotecas de servidor maduras, soluciones listas de IdP (Identity Providers) y autenticadores de hardware, lo que hace que la implementación sea significativamente más sencilla que hace unos años.
• Amenaza de las computadoras cuánticas (lejana, pero considerada): Aunque WebAuthn no es "resistente a la computación cuántica" en su implementación actual, su naturaleza modular permite actualizar fácilmente los algoritmos criptográficos en el futuro sin cambiar la arquitectura base del protocolo, lo cual es un factor importante para una estrategia de seguridad a largo plazo.

¿Qué problemas resuelve el artículo?

Este artículo está diseñado para resolver una serie de problemas clave que enfrentan los especialistas técnicos al considerar o implementar WebAuthn:

• Falta de una guía completa: Unificamos la información sobre WebAuthn para SSH/PAM y para aplicaciones web, proporcionando una visión integral de la implementación.
• Falta de ejemplos prácticos: Ofrecemos instrucciones paso a paso concretas, ejemplos de código y configuraciones para escenarios reales.
• Complejidad en la elección de la solución: Analizamos diferentes enfoques (integración nativa, IdP, desarrollo personalizado) con sus pros, contras y aspectos económicos.
• Problemas de escalabilidad y soporte: Abordamos cuestiones de gestión del ciclo de vida de las Passkeys, recuperación de acceso y monitoreo.
• Minimización de riesgos: Destacamos errores comunes y formas de prevenirlos, basados en la experiencia real.

¿Para quién está escrito?

Esta guía será de máxima utilidad para:

• Ingenieros DevOps y administradores de sistemas: Para proteger el acceso a servidores, sistemas de gestión de configuraciones y pipelines CI/CD utilizando WebAuthn a través de PAM y SSH.
• Desarrolladores Backend (Python, Node.js, Go, PHP): Para integrar WebAuthn en sus aplicaciones web, asegurando una autenticación de usuarios segura y moderna.
• Fundadores de proyectos SaaS y directores técnicos de startups: Para comprender las ventajas estratégicas de WebAuthn, evaluar costos, riesgos y elegir la ruta de implementación óptima, lo que les permitirá destacarse en el mercado gracias a un mayor nivel de seguridad y una mejor experiencia de usuario.
• Todos los interesados en las prácticas avanzadas de ciberseguridad: Para una inmersión profunda en una de las tecnologías de autenticación más significativas de la última década.

Criterios y factores clave para la implementación de WebAuthn

La elección y la implementación exitosa de WebAuthn requieren un análisis cuidadoso de múltiples factores. En 2026, cuando la tecnología ha alcanzado la madurez, es importante considerar no solo la funcionalidad básica, sino también las perspectivas a largo plazo, la integración con la infraestructura existente y la experiencia del usuario. A continuación, se presentan los criterios clave que deben evaluarse al planificar la implementación de WebAuthn.

1. Nivel de seguridad y resistencia a las amenazas

Este es el criterio más obvio, pero también el más profundo. WebAuthn es inherentemente resistente al phishing, ya que vincula la autenticación a un dominio específico (RP ID) y Origin, lo que imposibilita el uso de credenciales interceptadas en un sitio falso. Sin embargo, es importante evaluar otros aspectos:

• Protección contra ataques MITM: El protocolo FIDO2/WebAuthn utiliza TLS para proteger el canal de comunicación entre el cliente y el servidor, así como claves criptográficas que nunca abandonan el autenticador.
• Protección contra ataques de repetición: Cada solicitud de autenticación incluye un "challenge" único, generado por el servidor y que debe ser firmado por el autenticador. Esto evita la reutilización de respuestas interceptadas.
• Resistencia a la compromiso del servidor: Incluso si el servidor de la base de datos se ve comprometido, el atacante solo obtendrá las claves públicas y los metadatos, pero no las claves privadas, que se almacenan en el autenticador. Esto reduce significativamente el riesgo de compromiso masivo de credenciales.
• Tipos de atestación: Es importante comprender qué nivel de confianza desea tener en el autenticador. La atestación básica (None) es adecuada para la mayoría de los casos, pero para sistemas de alta seguridad puede requerirse G&D (Attestation Statement Format) u otros, que confirmen que el autenticador es un dispositivo de confianza.
• Protección contra ataques locales: Algunos autenticadores (por ejemplo, basados en TPM o Secure Enclave) ofrecen protección adicional para las claves privadas contra la extracción, incluso en caso de compromiso del dispositivo.

2. Experiencia del usuario (User Experience)

La seguridad no debe ir en detrimento de la comodidad. Las Passkeys buscan simplificar al máximo el proceso de autenticación. Evalúe los siguientes aspectos:

• Facilidad de registro: ¿Qué tan fácil es para el usuario registrar su Passkey? ¿Se requiere la instalación de software adicional? ¿Es el proceso intuitivo?
• Comodidad de autenticación: El proceso de inicio de sesión debe ser rápido y sin interrupciones. El escenario ideal es un solo toque o confirmación biométrica.
• Multiplataforma y sincronización: ¿La solución elegida admite la sincronización de Passkeys entre los dispositivos del usuario (por ejemplo, a través de iCloud Keychain, Google Password Manager, Microsoft Authenticator)? Esto es críticamente importante para las Passkeys.
• Manejo de errores y soporte: ¿Qué tan claros son los mensajes de error? ¿Es fácil para el usuario obtener ayuda si algo sale mal?
• Accesibilidad: ¿La solución tiene en cuenta las necesidades de los usuarios con discapacidades?

3. Compatibilidad e integración

WebAuthn es un estándar, pero su implementación puede variar. Es importante asegurarse de que la solución elegida funcione en su ecosistema:

• Soporte de navegadores y SO: Asegúrese de que todos los navegadores y sistemas operativos de destino de sus usuarios sean compatibles con WebAuthn y Passkeys. Para 2026, esto ya no es un gran problema, pero puede haber matices.
• Autenticadores de hardware: Si planea utilizar claves de hardware (YubiKey, SoloKeys), asegúrese de su compatibilidad con el sistema elegido y la facilidad de su emisión/gestión.
• Bibliotecas de servidor: Elija bibliotecas maduras y bien mantenidas para su backend (Python, Node.js, Go, PHP).
• Integración con sistemas existentes: ¿Cómo se integrará WebAuthn con su sistema de gestión de identidades (IdP), LDAP, Active Directory, PAM para SSH?
• Aplicaciones móviles: Si tiene aplicaciones móviles, ¿cómo se implementará la autenticación a través de WebAuthn/Passkeys en ellas? (API nativas para Passkeys).

4. Escalabilidad y gestionabilidad

A medida que crece su base de usuarios o la cantidad de recursos protegidos, el sistema de autenticación debe escalar sin un aumento significativo en los costos operativos:

• Gestión de credenciales: ¿Cómo gestionará miles o millones de Passkeys? ¿Se necesitan herramientas para la administración, revocación, recuperación?
• Monitoreo y auditoría: Capacidad para rastrear intentos de autenticación, identificar anomalías y generar informes para el cumplimiento normativo.
• Rendimiento: Impacto de WebAuthn en el rendimiento del servidor con un gran número de solicitudes simultáneas. (Generalmente mínimo, ya que la criptografía se realiza en el cliente).
• Facilidad de despliegue: ¿Qué tan fácil es desplegar y actualizar la solución WebAuthn en su infraestructura?

5. Costo y eficiencia económica

La implementación de cualquier nueva tecnología conlleva costos. Es importante evaluar tanto los gastos directos como los indirectos:

• Costos de desarrollo: Horas de desarrolladores para integración, pruebas, soporte.
• Costo de licencias: Si utiliza IdP de terceros o soluciones comerciales.
• Costos de hardware: Compra de autenticadores físicos, si son necesarios.
• Costos de capacitación: Capacitación de usuarios y del equipo de soporte.
• Costos ocultos: Tiempo para la resolución de problemas, soporte de sistemas de autenticación antiguos.
• Ahorros: Reducción de costos por restablecimiento de contraseñas, manejo de incidentes de seguridad, aumento de la productividad del usuario gracias a un inicio de sesión más rápido.

6. Recuperación de cuenta (Account Recovery)

Este es uno de los aspectos más críticos, a menudo subestimado. ¿Qué sucede si un usuario pierde todas sus Passkeys o autenticadores?

• Múltiples Passkeys: Se recomienda registrar varias Passkeys para una misma cuenta, utilizando diferentes dispositivos (por ejemplo, teléfono y portátil) o claves de hardware.
• Métodos de respaldo: Debe preverse un método seguro de respaldo para la recuperación de acceso (por ejemplo, a través de un correo electrónico/teléfono confirmado con un retraso, o a través del servicio de soporte con verificación reforzada). Este método debe estar lo más protegido posible contra el compromiso.
• Gestión de claves perdidas/robadas: Capacidad para revocar Passkeys comprometidas.

7. Cumplimiento normativo (Compliance)

En 2026, los requisitos de ciberseguridad son cada vez más estrictos. WebAuthn simplifica significativamente el cumplimiento de estándares como:

• GDPR, CCPA: Protección de datos personales mediante autenticación fuerte.
• NIST SP 800-63B: Cumplimiento de los requisitos de autenticación de alto nivel (AAL3).
• PCI DSS: Protección de datos de tarjetas de pago.
• HIPAA: Protección de información médica.

Cada uno de estos criterios requiere un análisis y una planificación detallados para garantizar una implementación exitosa, segura y económicamente eficiente de WebAuthn en su infraestructura.

Tabla comparativa de enfoques para la implementación de WebAuthn

La elección del enfoque óptimo para la implementación de WebAuthn depende de múltiples factores: el tamaño de su empresa, la especificidad de las aplicaciones, el presupuesto, los recursos internos y el nivel de control requerido. En 2026, existen varias estrategias maduras, cada una con sus ventajas y desventajas. A continuación, se presenta una tabla comparativa que le ayudará a orientarse en estas opciones, considerando las características y precios actuales.

Análisis detallado de cada punto/opción de implementación

Profundicemos en cada uno de los enfoques principales para la implementación de WebAuthn, analizados en la tabla comparativa. Esto le ayudará a comprender los matices que pueden influir en su decisión.

1. Integración nativa de WebAuthn con SSH/PAM en Linux

Este enfoque se centra en proteger el acceso a la propia infraestructura, como servidores, estaciones de trabajo e instancias en la nube, donde tradicionalmente se utiliza el acceso SSH y la autenticación local a través de PAM (Pluggable Authentication Modules). En 2026, esto se convierte en un estándar para entornos de alta seguridad.

Ventajas:

• Máximo nivel de seguridad: La integración directa con el núcleo de autenticación de Linux garantiza el control sobre cada aspecto. La protección contra ataques de phishing y MITM a nivel de acceso SSH es fundamental.
• Ausencia de dependencias externas: Una vez configurado, no depende de servicios de terceros o proveedores de la nube, lo cual es importante para entornos soberanos o altamente regulados.
• Control total: Usted controla completamente el proceso de registro de claves, su vinculación a los usuarios y la política de seguridad. Esto permite una configuración precisa del comportamiento del sistema.
• Cumplimiento normativo: Ideal para cumplir con estrictos estándares de seguridad (NIST AAL3, PCI DSS) que requieren un autenticador físico o biometría.
• Rentabilidad a escala: Después de la configuración inicial y la compra de claves de hardware (si se utilizan), los costos operativos son mínimos, ya que no hay pagos de licencias.

Desventajas:

• Complejidad de configuración: Requiere un conocimiento profundo de PAM, SSH y los conceptos criptográficos de FIDO2. La configuración puede ser laboriosa y propensa a errores.
• UX menos amigable para usuarios no técnicos: El proceso de registro de claves y autenticación a través de la CLI o en la consola puede ser menos intuitivo que en una interfaz web.
• Falta de sincronización entre dispositivos: Las Passkeys utilizadas para SSH/PAM suelen estar vinculadas a un autenticador físico (YubiKey, SoloKey) o a un autenticador de plataforma de una máquina específica. No hay sincronización automática, como ocurre con las Passkeys en la nube.
• Gestión de recuperación: Los mecanismos de recuperación de acceso en caso de pérdida de la clave deben desarrollarse manualmente, lo que añade complejidad.

Para quién es adecuado:

Ingenieros DevOps, administradores de sistemas, empresas con altos requisitos de seguridad de infraestructura, instituciones gubernamentales, organizaciones financieras, donde el acceso a los servidores requiere la máxima protección. Ideal para proteger entornos de producción, bases de datos, sistemas CI/CD.

Ejemplos de uso específicos:

La empresa "SecurHost" implementó pam_u2f para todos los accesos SSH a sus servidores de producción. Cada ingeniero DevOps recibió dos claves de hardware YubiKey (una principal y una de respaldo). Al intentar una conexión SSH al servidor, además de ingresar la contraseña (o sin ella, según la configuración), el sistema requiere la confirmación tocando el YubiKey. Esto eliminó por completo la posibilidad de un hackeo remoto de los servidores a través de claves SSH o contraseñas comprometidas, incluso si estas fueran robadas.

2. Implementación personalizada de WebAuthn para aplicaciones web

Este enfoque implica el desarrollo independiente de la lógica del lado del servidor y del cliente para admitir WebAuthn en su aplicación web. Ofrece la máxima flexibilidad, pero requiere importantes recursos de ingeniería.

Ventajas:

• Máxima flexibilidad y personalización: Puede controlar completamente la interfaz de usuario, la lógica de registro y autenticación, así como la integración con su sistema de usuarios existente.
• Ausencia de bloqueo de proveedor: No está vinculado a un proveedor de servicios de identidad específico, lo que le permite evitar la dependencia y los posibles costos futuros.
• Optimización para necesidades específicas: Posibilidad de implementar escenarios únicos que no son compatibles con las soluciones IdP listas para usar.
• Control total sobre los datos: Todos los datos de usuario y metadatos de Passkeys permanecen bajo su control.

Desventajas:

• Alta complejidad de desarrollo: Requiere una comprensión profunda de la especificación WebAuthn, la criptografía y experiencia en el desarrollo de aplicaciones web seguras. Esta no es una tarea trivial.
• Costos de desarrollo significativos: El desarrollo, las pruebas y el mantenimiento de un sistema de este tipo requieren importantes recursos de ingeniería y tiempo. Los errores pueden dar lugar a vulnerabilidades graves.
• Carga de seguridad: La responsabilidad de la implementación correcta de todos los aspectos de seguridad (validación, almacenamiento, revocación) recae completamente en su equipo.
• Largo tiempo de lanzamiento: En comparación con las soluciones IdP listas para usar, el tiempo de desarrollo e implementación será significativamente mayor.

Para quién es adecuado:

Grandes empresas con un sólido equipo de seguridad y desarrollo que tienen requisitos de autenticación únicos o no pueden utilizar servicios de terceros por razones regulatorias. También es adecuado para proyectos SaaS de nicho que desean ofrecer una experiencia de usuario única y totalmente controlada.

Ejemplos de uso específicos:

La startup fintech "CryptoVault" desarrolló su propio sistema WebAuthn para proteger las cuentas de sus usuarios que almacenan criptomonedas. Debido a los estrictos requisitos de seguridad y confidencialidad, así como a la necesidad de una configuración UX precisa para una audiencia específica, decidieron no utilizar IdP de terceros. Su backend en Go utiliza la biblioteca go-webauthn, y el frontend en React.js – @simplewebauthn/browser. Esto les permitió integrar funciones únicas, como la autenticación multifactor con múltiples Passkeys y la vinculación a transacciones específicas.

3. Uso de un Proveedor de Identidad (IdP) con soporte WebAuthn

Este enfoque implica delegar las funciones de autenticación a un servicio de terceros (por ejemplo, Auth0, Okta, Keycloak) que ya cuenta con soporte integrado para WebAuthn y Passkeys.

Ventajas:

• Implementación rápida (Time-to-Market): La mayoría de los IdP ofrecen SDK y API que simplifican significativamente la integración de WebAuthn en sus aplicaciones. Puede lanzar Passkeys en cuestión de días o semanas.
• Reducción de la carga de seguridad: La responsabilidad de la implementación correcta del protocolo WebAuthn, su actualización y el cumplimiento de los estándares recae en el IdP.
• Excelente experiencia de usuario: Los IdP suelen tener interfaces de usuario bien diseñadas para el registro y la autenticación, incluido el soporte para Passkeys entre dispositivos.
• Gestión centralizada: Un único punto de gestión para todos los usuarios y sus credenciales en múltiples aplicaciones.
• Funcionalidad rica: Además de WebAuthn, los IdP ofrecen muchas otras funciones: SSO, MFA, inicios de sesión sociales, gestión de roles, auditoría, etc.
• Escalabilidad: Los IdP están diseñados para manejar millones de usuarios y proporcionar alta disponibilidad.

Desventajas:

• Bloqueo de proveedor: Usted se vuelve dependiente del IdP elegido. La migración a otro proveedor puede ser compleja y costosa.
• Costo: Los servicios de IdP pueden ser costosos, especialmente para grandes volúmenes de usuarios o si se requieren funciones avanzadas. Los precios en 2026 continúan aumentando.
• Personalización limitada: Aunque muchos IdP ofrecen opciones de personalización de la interfaz de usuario, usted sigue limitado por su framework.
• Cuestiones de privacidad de datos: Los datos de sus usuarios y sus metadatos de Passkeys se almacenan en un proveedor externo, lo que puede ser un problema para algunas empresas o en ciertas jurisdicciones.
• Complejidad de integración con SSH/PAM: La mayoría de los IdP se centran en la autenticación web. La integración con SSH/PAM puede requerir esfuerzos adicionales o el uso de pasarelas especializadas.

Para quién es adecuado:

Empresas SaaS, startups, medianas y grandes empresas que desean implementar rápidamente una autenticación robusta sin gastar recursos significativos en el desarrollo de funcionalidades básicas. Ideal para aplicaciones donde la experiencia del usuario y la velocidad de comercialización son prioritarias.

Ejemplos de uso específicos:

La plataforma SaaS de gestión de proyectos "TeamFlow" se enfrentó al problema de frecuentes solicitudes de soporte debido a contraseñas perdidas y ataques de phishing a sus clientes. Implementaron Auth0, utilizando su soporte integrado para WebAuthn. Los usuarios ahora pueden registrar Passkeys desde sus teléfonos inteligentes o computadoras portátiles, obteniendo acceso sin contraseña. Esto resultó en una reducción del 40% en las solicitudes de soporte y un aumento significativo en la satisfacción del cliente.

4. Enfoque híbrido (PAM + IdP)

Este enfoque combina la integración nativa de WebAuthn para proteger la infraestructura (SSH/PAM) con el uso de un IdP para aplicaciones web. Ofrece lo mejor de ambos mundos.

Ventajas:

• Seguridad integral: Protege tanto la infraestructura interna como las aplicaciones web externas utilizando los métodos de autenticación más modernos.
• UX optimizado: Los usuarios obtienen una excelente experiencia en aplicaciones web a través del IdP, y el personal técnico, un acceso fiable y controlado a los servidores.
• Flexibilidad: Puede elegir la solución más adecuada para cada parte de su ecosistema.
• Escalabilidad y gestionabilidad: El IdP proporciona una gestión centralizada de usuarios para las aplicaciones web, y PAM, para los servidores.

Desventajas:

• Alta complejidad general: Requiere la integración y gestión de dos sistemas de autenticación diferentes, lo que aumenta la complejidad de la arquitectura y el soporte.
• Potencial duplicación de esfuerzos: Algunos aspectos (por ejemplo, la gestión de usuarios) pueden requerir la sincronización entre el IdP y los sistemas locales.
• Costos generales: Combina los costos de desarrollo de la integración nativa y las tarifas de licencia del IdP.

Para quién es adecuado:

Grandes empresas que tienen una infraestructura compleja (muchos servidores, bases de datos) y, al mismo tiempo, numerosas aplicaciones web internas y externas. Esta es una solución para empresas que buscan la máxima seguridad y comodidad en todos los aspectos de su ecosistema digital.

Ejemplos de uso específicos:

La empresa de consultoría internacional "GlobalSecure" utiliza un enfoque híbrido. Para sus desarrolladores internos y administradores de sistemas que trabajan con infraestructura en la nube y on-premise, se ha implementado la autenticación WebAuthn a través de PAM para el acceso SSH. Todos los empleados utilizan claves de hardware YubiKey. Para acceder a las aplicaciones web internas (CRM, portal de RRHH, sistemas de informes) y a los productos SaaS externos proporcionados a los clientes, se utiliza Azure AD con soporte para Passkeys, lo que garantiza un inicio de sesión único y comodidad para todos los usuarios. Esto permite a la empresa cumplir con los estrictos estándares de seguridad de los clientes y, al mismo tiempo, mantener una alta productividad.

Consejos prácticos y recomendaciones para la implementación de WebAuthn

La implementación de WebAuthn, ya sea para acceso SSH o aplicaciones web, requiere atención a los detalles. Estos consejos y ejemplos prácticos le ayudarán a evitar errores comunes y a garantizar un funcionamiento fiable del sistema.

1. Implementación de WebAuthn para SSH/PAM en Linux

Para proteger el acceso SSH en Linux, utilizaremos pam_u2f, un módulo PAM que permite el uso de autenticadores compatibles con FIDO2 (incluidas las Passkeys, si funcionan como dispositivos CTAP2) para la autenticación en el sistema. En 2026, este módulo es una solución madura.

Paso 1: Instalación de los paquetes necesarios

Asegúrese de tener instalados libfido2 y pam_u2f. Dependiendo de su distribución de Linux, los comandos pueden variar.

# Para Debian/Ubuntu (actualizado para 2026)
sudo apt update
sudo apt install libfido2-dev libpam-u2f -y

# Para RHEL/CentOS/Fedora
sudo dnf install libfido2-devel pam_u2f -y
    

Paso 2: Registro de su clave FIDO2 (Passkey)

Cada usuario debe registrar su clave FIDO2. Este proceso crea un archivo de mapeo único entre el usuario de Linux y el identificador de la clave. Utilice la utilidad pamu2fcfg.

# Como el usuario que utilizará la clave
pamu2fcfg -u $(whoami) > ~/.config/Yubico/u2f_keys

# Ejemplo del contenido de ~/.config/Yubico/u2f_keys:
# username:key_handle,public_key
# user1:AQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHyAhIiMkJSYnKCkqKywtLi8wMTIzNDU2Nzg5Ojs8PT4/QEFCD...
    

Importante: Asegúrese de que su clave FIDO2 esté conectada cuando ejecute este comando. Para las Passkeys almacenadas en un autenticador de plataforma (por ejemplo, un smartphone), el proceso puede ser más complejo y requerir el uso de software especial o la emulación de un dispositivo USB.

Para una gestión centralizada de claves en un entorno corporativo, se pueden almacenar los u2f_keys en un directorio centralizado (por ejemplo, NFS, LDAP) y configurar pam_u2f para que los utilice.

Paso 3: Configuración de PAM para SSH

Edite el archivo de configuración de PAM para SSH. Normalmente es /etc/pam.d/sshd.

sudo nano /etc/pam.d/sshd
    

Añada la siguiente línea al principio del archivo, antes de cualquier otra directiva auth. Esto proporcionará autenticación de dos factores (contraseña + clave).

# Añadir al principio
auth       required   pam_u2f.so cue [debug] authfile=/etc/Yubico/u2f_keys store_directory=/etc/Yubico

# Si desea permitir el uso del archivo de claves en el directorio personal del usuario:
# auth       required   pam_u2f.so cue [debug]
    

Parámetros:

• cue: Solicita al usuario que toque la clave.
• debug: Útil para la depuración.
• authfile=/etc/Yubico/u2f_keys: Apunta a un archivo centralizado con las claves (si se utiliza). Si no se especifica, el módulo busca ~/.config/Yubico/u2f_keys.
• store_directory=/etc/Yubico: Directorio para almacenar metadatos.

Si desea un inicio de sesión completamente sin contraseña con una clave FIDO2, necesitará una configuración de PAM más compleja, posiblemente utilizando sufficient en lugar de required, pero esto requiere una planificación cuidadosa y métodos de respaldo.

Paso 4: Configuración del demonio SSH

Edite el archivo de configuración del demonio SSH /etc/ssh/sshd_config.

sudo nano /etc/ssh/sshd_config
    

Asegúrese de que los siguientes parámetros estén configurados:

ChallengeResponseAuthentication yes
UsePAM yes
AuthenticationMethods publickey,keyboard-interactive
    

AuthenticationMethods indica que el usuario puede autenticarse mediante una clave pública (si está configurada) O mediante una respuesta interactiva (PAM, que ahora incluye U2F/FIDO2). Reinicie el demonio SSH:

sudo systemctl restart sshd
    

Paso 5: Pruebas

Abra una nueva sesión de terminal (¡no cierre la actual hasta que se asegure de que todo funciona!). Intente conectarse al servidor por SSH. Se le pedirá que introduzca la contraseña y luego que toque la clave.

ssh user@your_server_ip
    

Si utiliza Passkeys sincronizadas con su smartphone, es posible que deba confirmar el inicio de sesión en el teléfono.

2. Implementación de WebAuthn para aplicaciones web (ejemplo Python/Node.js)

Para las aplicaciones web, el proceso incluye tanto la parte del servidor como la del cliente. Revisaremos la lógica general.

Paso 1: Selección de la biblioteca del servidor

Utilice una biblioteca madura y bien mantenida para su backend.

• Python: fido2 (de Yubico) o py_webauthn.
• Node.js: @simplewebauthn/server.
• Go: go-webauthn.
• PHP: web-authn/web-authn.

Paso 2: Configuración de RP ID y Origin

Estos son parámetros críticos. rpId (Relying Party ID) es el dominio que es la fuente de la solicitud de autenticación. origin es la URL completa, incluyendo el esquema y el puerto. Deben coincidir exactamente. Para rpId, normalmente se utiliza el dominio (por ejemplo, example.com).

// Node.js (ejemplo)
const rpId = 'your-domain.com'; // Utilice el dominio raíz sin subdominios, si las Passkeys deben funcionar en todos los subdominios.
const origin = https://${rpId}; // URL completa con HTTPS.
    

Paso 3: Implementación del registro (Enrollment)

El proceso de registro consta de dos etapas: solicitud de opciones de registro y finalización del registro.

Parte del servidor (Node.js con @simplewebauthn/server):

// 1. /api/generate-registration-options
import { generateRegistrationOptions } from '@simplewebauthn/server';
import { origin, rpId } from './config'; // Su RP ID y Origin

app.post('/api/generate-registration-options', async (req, res) => {
    const { userId, userName } = req.body; // Obtenemos el ID y el nombre de usuario

    const options = await generateRegistrationOptions({
        rpName: 'My Secure App', // Nombre de su empresa/aplicación
        rpId: rpId,
        userID: userId,
        userName: userName,
        attestationType: 'none', // Suficiente para la mayoría de los casos
        authenticatorSelection: {
            authenticatorAttachment: 'cross-platform', // 'platform' para integrados, 'cross-platform' para externos (YubiKey)
            userVerification: 'preferred', // Preferimos biometría/PIN
        },
        timeout: 60000, // 60 segundos
        // Opciones adicionales, por ejemplo, excludeCredentials para evitar el registro de una misma clave varias veces
        excludeCredentials: await getExistingCredentialsForUser(userId),
    });

    // Guarde el challenge en el servidor, vinculado a la sesión del usuario, para su posterior validación
    req.session.currentChallenge = options.challenge;
    res.json(options);
});

// 2. /api/verify-registration
import { verifyRegistrationResponse } from '@simplewebauthn/server';

app.post('/api/verify-registration', async (req, res) => {
    const { registrationResponse } = req.body; // Respuesta del cliente

    try {
        const verification = await verifyRegistrationResponse({
            response: registrationResponse,
            expectedChallenge: req.session.currentChallenge, // Usamos el challenge de la sesión
            expectedOrigin: origin,
            expectedRPID: rpId,
            requireUserVerification: true, // Requerimos verificación de usuario (PIN/biometría)
        });

        const { verified, registrationInfo } = verification;
        if (verified && registrationInfo) {
            const { credentialID, credentialPublicKey, counter } = registrationInfo;
            // Guarde credentialID, credentialPublicKey, counter en su base de datos, vinculados a userId
            // credentialPublicKey debe guardarse en formato COSE_KEY (Buffer)
            // counter - para protección contra ataques de repetición
            await saveCredentialToDatabase(userId, credentialID, credentialPublicKey, counter);
            res.json({ success: true, msg: '¡Passkey registrado con éxito!' });
        } else {
            res.status(400).json({ success: false, msg: 'Error de registro de Passkey.' });
        }
    } catch (error) {
        console.error('Error de verificación de registro:', error);
        res.status(400).json({ success: false, msg: error.message });
    }
});
    

Parte del cliente (JavaScript con @simplewebauthn/browser):

import { startRegistration } from '@simplewebauthn/browser';

async function registerPasskey(userId, userName) {
    try {
        // 1. Solicitud de opciones de registro al servidor
        const resp = await fetch('/api/generate-registration-options', {
            method: 'POST',
            headers: { 'Content-Type': 'application/json' },
            body: JSON.stringify({ userId, userName }),
        });
        const options = await resp.json();

        // 2. Inicio del proceso de registro en el navegador
        const attResp = await startRegistration(options);

        // 3. Envío de la respuesta del navegador al servidor para verificación
        const verificationResp = await fetch('/api/verify-registration', {
            method: 'POST',
            headers: { 'Content-Type': 'application/json' },
            body: JSON.stringify({ registrationResponse: attResp }),
        });
        const verificationResult = await verificationResp.json();

        if (verificationResult.success) {
            alert('¡Passkey registrado con éxito!');
        } else {
            alert('Error de registro: ' + verificationResult.msg);
        }
    } catch (error) {
        console.error('Error en el proceso de registro:', error);
        alert('Ocurrió un error al registrar la Passkey.');
    }
}
    

Paso 4: Implementación de la autenticación

El proceso de autenticación también consta de dos etapas: solicitud de opciones de autenticación y finalización de la autenticación.

Parte del servidor (Node.js con @simplewebauthn/server):

// 1. /api/generate-authentication-options
import { generateAuthenticationOptions } from '@simplewebauthn/server';

app.post('/api/generate-authentication-options', async (req, res) => {
    const { userName } = req.body; // O userId, si lo conoce

    // Obtenemos la lista de credentialIDs registrados para este usuario
    const userCredentials = await getCredentialsByUserName(userName);

    const options = await generateAuthenticationOptions({
        rpId: rpId,
        // Permitimos que el navegador ofrezca solo las Passkeys que conocemos
        allowCredentials: userCredentials.map(cred => ({
            id: cred.credentialID,
            type: 'public-key',
            transports: ['usb', 'nfc', 'ble', 'internal'], // Indicamos los transportes posibles
        })),
        userVerification: 'preferred',
        timeout: 60000,
    });

    // Guarde el challenge en el servidor, vinculado a la sesión del usuario
    req.session.currentChallenge = options.challenge;
    res.json(options);
});

// 2. /api/verify-authentication
import { verifyAuthenticationResponse } from '@simplewebauthn/server';

app.post('/api/verify-authentication', async (req, res) => {
    const { authenticationResponse } = req.body;

    // Obtenemos los datos de la Passkey de la BD por el credentialID que llegó en authenticationResponse
    const credential = await getCredentialById(authenticationResponse.id);
    if (!credential) {
        return res.status(400).json({ success: false, msg: 'Clave no encontrada.' });
    }

    try {
        const verification = await verifyAuthenticationResponse({
            response: authenticationResponse,
            expectedChallenge: req.session.currentChallenge,
            expectedOrigin: origin,
            expectedRPID: rpId,
            authenticator: {
                credentialID: credential.credentialID,
                credentialPublicKey: credential.credentialPublicKey,
                counter: credential.counter, // Para verificar el contador
            },
            requireUserVerification: true,
        });

        const { verified, authenticationInfo } = verification;
        if (verified) {
            // Actualice el contador en la BD para este credentialID
            await updateCredentialCounter(credential.credentialID, authenticationInfo.newCounter);
            // Autenticación exitosa, establecemos la sesión del usuario
            req.session.userId = credential.userId;
            res.json({ success: true, msg: '¡Inicio de sesión exitoso!' });
        } else {
            res.status(400).json({ success: false, msg: 'Error de autenticación.' });
        }
    } catch (error) {
        console.error('Error de verificación de autenticación:', error);
        res.status(400).json({ success: false, msg: error.message });
    }
});
    

Parte del cliente (JavaScript con @simplewebauthn/browser):

import { startAuthentication } from '@simplewebauthn/browser';

async function authenticateWithPasskey(userName) {
    try {
        // 1. Solicitud de opciones de autenticación al servidor
        const resp = await fetch('/api/generate-authentication-options', {
            method: 'POST',
            headers: { 'Content-Type': 'application/json' },
            body: JSON.stringify({ userName }),
        });
        const options = await resp.json();

        // 2. Inicio del proceso de autenticación en el navegador
        const authResp = await startAuthentication(options);

        // 3. Envío de la respuesta del navegador al servidor para verificación
        const verificationResp = await fetch('/api/verify-authentication', {
            method: 'POST',
            headers: { 'Content-Type': 'application/json' },
            body: JSON.stringify({ authenticationResponse: authResp }),
        });
        const verificationResult = await verificationResp.json();

        if (verificationResult.success) {
            alert('¡Inicio de sesión exitoso!');
            window.location.href = '/dashboard'; // Redirección
        } else {
            alert('Error de inicio de sesión: ' + verificationResult.msg);
        }
    } catch (error) {
        console.error('Error en el proceso de autenticación:', error);
        alert('Ocurrió un error al iniciar sesión con Passkey.');
    }
}
    

3. Recomendaciones generales para ambos enfoques

• Claves de respaldo: Siempre anime a los usuarios a registrar varias Passkeys o a tener un método de autenticación de respaldo. Esto es fundamental para la recuperación del acceso.
• Ciclo de vida de las claves: Desarrolle procedimientos para revocar claves perdidas/comprometidas y reemplazarlas.
• Registro (Logging): Registre cuidadosamente todos los eventos relacionados con el registro y la autenticación. Esto ayudará en la depuración y la auditoría de seguridad.
• Capacitación de usuarios: Explique a los usuarios cómo funcionan las Passkeys, por qué son más seguras y cómo utilizarlas. Esto reducirá el número de solicitudes de soporte.
• HTTPS en todas partes: WebAuthn exige estrictamente HTTPS. Asegúrese de que su sitio web o API solo sean accesibles a través de una conexión segura.
• Pruebas: Realice pruebas exhaustivas en diferentes dispositivos, navegadores y autenticadores.

Estas recomendaciones y ejemplos de código proporcionan una base sólida para empezar a trabajar con WebAuthn. Recuerde que la seguridad es un proceso continuo, y su implementación debe revisarse y actualizarse regularmente.

Errores comunes al implementar WebAuthn

La implementación de una tecnología compleja como WebAuthn conlleva ciertas trampas. Basándonos en la experiencia de 2026, hemos identificado los errores más frecuentes que cometen desarrolladores y administradores, y proponemos formas de prevenirlos.

1. Configuración incorrecta de RP ID y Origin

Error: Uso de un rpId (Relying Party ID) o origin incorrecto. Por ejemplo, establecer el rpId en un dominio completo con subdominio (app.example.com) en lugar del raíz (example.com), o una falta de coincidencia de protocolo (HTTP en lugar de HTTPS).

Consecuencias: WebAuthn no funcionará. El navegador rechazará las solicitudes de autenticación/registro debido a la falta de coincidencia. Este es un error fundamental que compromete la seguridad del protocolo, ya que el rpId es una vinculación al origen. Si el rpId está configurado como app.example.com, entonces la Passkey no funcionará para sub.app.example.com, lo que puede ser un comportamiento inesperado.

Cómo evitarlo:

• Utilice siempre el dominio raíz para el rpId si desea que las Passkeys funcionen en todos los subdominios. Por ejemplo, para app.example.com y test.example.com, use example.com como rpId.
• El origin debe coincidir exactamente con la URL actual, incluyendo el esquema (https://) y el puerto.
• Lea atentamente la documentación de su biblioteca de servidor WebAuthn, ya que puede tener sus propios matices en el manejo de estos parámetros.
• Utilice solo HTTPS. WebAuthn está estrictamente prohibido para HTTP.

2. Ausencia o mecanismos inadecuados de recuperación de acceso

Error: Asumir que los usuarios nunca perderán su Passkey o todos sus autenticadores. No proporcionar una forma segura y clara de recuperar el acceso.

Consecuencias: Bloqueo de usuarios, pérdida de datos, una enorme carga para el servicio de soporte, una experiencia de usuario negativa y el posible abandono del uso de WebAuthn.

Cómo evitarlo:

• Múltiples Passkeys: Anime a los usuarios a registrar varias Passkeys en diferentes dispositivos (smartphone, portátil, llave de hardware) o a tener varias llaves de hardware.
• Códigos de respaldo: Proporcione a los usuarios la opción de generar códigos de respaldo de un solo uso que puedan guardar en un lugar seguro.
• Retraso en la recuperación: Implemente un procedimiento de recuperación de acceso que incluya un retraso (por ejemplo, 24-48 horas) antes de activar un nuevo método, para dar tiempo al usuario a reaccionar si la solicitud de recuperación fue iniciada por un atacante.
• Verificación reforzada: Para la recuperación a través del servicio de soporte, requiera una verificación multifactor de la identidad del usuario (por ejemplo, respuestas a preguntas secretas, confirmación por videollamada, identificación con documentos).
• Transición gradual: En las etapas iniciales, mantenga los métodos tradicionales de 2FA como respaldo hasta que los usuarios se acostumbren a las Passkeys.

3. Validación incorrecta de las respuestas del autenticador en el servidor

Error: Validación incompleta o incorrecta de todos los campos devueltos por el autenticador (por ejemplo, challenge, origin, rpId, signature, counter, userVerification).

Consecuencias: Vulnerabilidades a ataques de repetición (replay-attacks), suplantación de autenticación, elusión de seguridad. Este es uno de los errores más graves, ya que puede comprometer completamente el sistema de autenticación.

Cómo evitarlo:

• Utilice bibliotecas probadas: Confíe siempre en bibliotecas de servidor WebAuthn maduras y bien probadas que implementen todas las verificaciones necesarias según la especificación FIDO2.
• Verifique el challenge: Asegúrese de que el challenge recibido en la respuesta de autenticación coincida con el que envió originalmente y guardó en la sesión del usuario (y que sea criptográficamente aleatorio y de un solo uso).
• Verifique el origin y el rpId: Deben coincidir exactamente con sus valores esperados.
• Verifique la signature: La firma debe ser válida y realizada con la clave pública registrada para esa Passkey.
• Verifique el counter: Asegúrese de que el valor del contador devuelto por el autenticador sea mayor que el valor previamente guardado. Esto protege contra ataques de repetición (replay-attacks).
• Verifique userVerification: Si requiere la verificación del usuario (PIN/biometría), asegúrese de que la bandera uv esté establecida en la respuesta.

4. Ignorar el ciclo de vida y la gestión de las Passkeys

Error: Ausencia de mecanismos para ver, revocar o actualizar las Passkeys registradas para un usuario.

Consecuencias: Dificultades para los usuarios que desean eliminar una clave antigua, o para los administradores que necesitan revocar una clave comprometida. Esto puede llevar a claves "muertas" que continúan proporcionando acceso, o a la imposibilidad de gestionar la seguridad.

Cómo evitarlo:

• Panel de gestión de claves: Proporcione a los usuarios en su perfil la capacidad de ver sus Passkeys registradas, asignarles nombres claros y eliminarlas.
• Panel administrativo: Los administradores deben tener la capacidad de revocar Passkeys de forma forzada para cualquier usuario en caso de un incidente de seguridad.
• Revocación automática: Considere la posibilidad de revocar automáticamente las Passkeys que no se hayan utilizado durante mucho tiempo, o en ciertos eventos (por ejemplo, después de la recuperación de la cuenta a través de un método de respaldo).

5. Mala información y formación de los usuarios

Error: Implementar WebAuthn sin una explicación adecuada a los usuarios sobre qué es, cómo funciona, por qué es más seguro y cómo usarlo.

Consecuencias: Confusión de los usuarios, resistencia a la nueva tecnología, aumento de las consultas al soporte con preguntas como "¿qué es esta ventana?" o "¿dónde está mi contraseña?".

Cómo evitarlo:

• Guías detalladas: Cree instrucciones paso a paso claras y preguntas frecuentes (FAQ) para los usuarios.
• UX intuitivo: El diseño de la interfaz para el registro y la autenticación debe ser lo más simple y comprensible posible.
• Textos explicativos: Añada breves explicaciones en la UI cuando el usuario se encuentre con una solicitud de WebAuthn.
• Canales de soporte: Asegúrese de que el servicio de soporte esté capacitado en WebAuthn y pueda responder rápidamente a las preguntas de los usuarios.
• Ventajas: Enfatice los beneficios (conveniencia, seguridad, ausencia de contraseñas) para fomentar la adopción.

Al evitar estos errores comunes, podrá garantizar una implementación de WebAuthn más fluida, segura y exitosa en su infraestructura y aplicaciones.

Lista de verificación para la aplicación práctica de WebAuthn

Para garantizar una implementación exitosa y segura de WebAuthn (Passkeys) en su infraestructura y aplicaciones web, siga este algoritmo paso a paso. Esta lista de verificación cubre las etapas clave, desde la planificación hasta el lanzamiento y el soporte.

Etapa 1: Planificación y arquitectura

1. Definir el objetivo de la implementación:
   • ¿Protección del acceso SSH a servidores?
   • ¿Inicio de sesión sin contraseña para aplicaciones web?
   • ¿Cumplimiento de requisitos normativos (NIST, PCI DSS)?
   • ¿Mejora de la UX y reducción de la carga de soporte?
2. Elegir el enfoque de implementación:
   • ¿Integración nativa SSH/PAM?
   • ¿Implementación personalizada para aplicaciones web?
   • ¿Uso de un Identity Provider (IdP)?
   • ¿Enfoque híbrido?
3. Definir la estrategia de rpId y origin:
   • Elegir el dominio raíz para rpId, si se requiere soporte para subdominios.
   • Asegurarse de que origin siempre use HTTPS.
4. Diseñar mecanismos de recuperación de acceso:
   • Prever el registro de múltiples Passkeys.
   • Definir métodos de respaldo (por ejemplo, códigos de respaldo, confirmación por correo electrónico/SMS con retraso).
   • Desarrollar un procedimiento de recuperación a través del servicio de soporte.
5. Planificar la gestión del ciclo de vida de las Passkeys:
   • Mecanismos para que los usuarios vean, renombren, revoquen y eliminen claves.
   • Herramientas administrativas para la revocación de claves.
6. Evaluar la compatibilidad:
   • Navegadores y sistemas operativos de los usuarios objetivo.
   • Autenticadores de hardware compatibles (si aplica).

Etapa 2: Implementación y desarrollo

7. Para SSH/PAM (si se elige este enfoque):
   • Instalar libfido2 y pam_u2f.
   • Configurar el registro de claves con pamu2fcfg (localmente o centralizado).
   • Configurar /etc/pam.d/sshd para usar pam_u2f.so.
   • Configurar /etc/ssh/sshd_config (ChallengeResponseAuthentication yes, UsePAM yes).
   • Probar el acceso SSH con una clave FIDO2.
8. Para aplicaciones web (si se elige este enfoque):
   • Elegir e integrar una biblioteca de servidor WebAuthn (por ejemplo, py_webauthn, @simplewebauthn/server).
   • Implementar puntos finales para generar opciones de registro (GET /register/options).
   • Implementar puntos finales para verificar la respuesta de registro (POST /register/verify).
   • Implementar puntos finales para generar opciones de autenticación (GET /login/options).
   • Implementar puntos finales para verificar la respuesta de autenticación (POST /login/verify).
   • Desarrollar la lógica JavaScript del cliente para interactuar con la API WebAuthn del navegador (por ejemplo, con @simplewebauthn/browser).
   • Garantizar el almacenamiento seguro de los metadatos de las Passkeys (credentialID, credentialPublicKey, counter) en su base de datos.
9. Para la integración con IdP (si se elige este enfoque):
   • Registrarse con el IdP elegido (Auth0, Okta, Keycloak).
   • Configurar el dominio del IdP y su aplicación en su panel de control.
   • Habilitar el soporte para WebAuthn/Passkeys en la configuración del IdP.
   • Integrar el SDK/API del IdP en su aplicación web para redirigir a las páginas de autenticación del IdP.
   • Configurar la URL de callback para el retorno del usuario después de una autenticación exitosa.
10. Garantizar HTTPS: Asegurarse de que todos los puntos finales relacionados con WebAuthn sean accesibles solo a través de HTTPS.

Etapa 3: Pruebas y despliegue

11. Realizar pruebas exhaustivas:
    • Pruebas de registro y autenticación en diferentes navegadores (Chrome, Firefox, Safari, Edge).
    • Pruebas en diferentes plataformas (Windows, macOS, Android, iOS).
    • Pruebas con diferentes autenticadores (de plataforma, multiplataforma, claves de hardware).
    • Pruebas de escenarios de pérdida de clave y recuperación de acceso.
    • Pruebas de errores de validación (challenge incorrecto, rpId, etc.).
12. Desarrollar documentación para los usuarios:
    • Instrucciones paso a paso para el registro y uso de Passkeys.
    • Preguntas frecuentes sobre problemas comunes.
    • Instrucciones para la recuperación de acceso.
13. Capacitar al equipo de soporte:
    • Cómo funciona WebAuthn.
    • Cómo ayudar a los usuarios con el registro/autenticación.
    • Procedimientos de recuperación de acceso.
14. Implementar registro y monitoreo:
    • Registrar todos los eventos de registro y autenticación.
    • Monitorear intentos de inicio de sesión anómalos o errores frecuentes.
15. Despliegue gradual:
    • Comenzar con un grupo piloto de usuarios.
    • Expandir gradualmente la disponibilidad a todos los usuarios.
    • Inicialmente, ofrecer WebAuthn como una opción, no como un método obligatorio, para que los usuarios puedan acostumbrarse.