Las pruebas de WebAuthn surgieron a medida que los estándares FIDO2 reemplazaron el legado U2F, introduciendo complejas máquinas de estado de ceremonia que involucran datos del cliente, objetos de atestación y desafíos criptográficos. El problema central radica en la heterogeneidad de los autenticadores; los autenticadores de plataforma como Windows Hello difieren radicalmente del hardware móvil como YubiKey en lo que respecta al almacenamiento de claves residentes, protocolos de transporte (USB, NFC, BLE) y requisitos de UV, mientras que los navegadores imponen diferentes políticas de permisos para contextos de origen cruzado. Una metodología manual sistemática requiere un mapeo de taxonomía de autenticadores, donde cada dispositivo se clasifica según su formato de atestación (packed, tpm, fido-u2f), capacidades y disponibilidad de transporte. Los testers deben ejecutar manualmente las ceremonias de registro y autenticación a través de Chrome, Safari, Firefox y Edge, inspeccionando los objetos de atestación codificados en CBOR a través de las herramientas de desarrollo del navegador para verificar la estructura fmt y attStmt contra el Servicio de Metadatos de FIDO (MDS). Se debe prestar especial atención a los contextos de iframe de origen cruzado, validando que los permisos allow="publickey-credentials-create" y allow="publickey-credentials-get" se apliquen correctamente, y que los flujos de clave residente manejen adecuadamente el filtro excludeCredentials para prevenir registros duplicados.
Un portal de salud integrado el registro de WebAuthn dentro de un widget de React servido desde un subdominio de CDN, permitiendo a los médicos utilizar YubiKey 5 NFC para autenticación de segundo factor o macOS Touch ID para inicio de sesión sin contraseña. Los médicos informaron fallos intermitentes donde Safari en iOS no reconocía el YubiKey a través de NFC tras un registro exitoso en Chrome de escritorio, y los avisos de Touch ID fallaron silenciosamente cuando el widget se cargó en un iframe de origen cruzado dentro del sistema de registros de salud electrónicos Epic del hospital. Consideramos tres enfoques distintos para aislar la causa raíz de estas fallas de integración específicas de hardware.
La primera solución involucró pruebas automatizadas con autenticadores virtuales a través de Puppeteer o Selenium utilizando el protocolo de autenticador virtual WebDriver. Este método ofrece alta velocidad y perfecta repetibilidad para pruebas de regresión en el manejo del desafío-respuesta del lado del servidor y la lógica de análisis de CBOR. Sin embargo, no logra reproducir peculiaridades específicas de hardware—como las pistas de transporte de YubiKey que entran en conflicto con la implementación NFC de Safari o las diferencias en la política de permisos de iframe entre Chrome y Safari—y no puede simular avisos biométricos de UV o interacciones físicas de toque.
La segunda solución propuso pruebas manuales ad-hoc utilizando cualquier dispositivo disponible en la oficina para proporcionar comentarios inmediatos sobre la experiencia del usuario. Si bien este enfoque captura el comportamiento real del navegador, resulta en una cobertura y reproducibilidad inconsistentes; los testers a menudo pasaron por alto que los dispositivos Android requieren emparejamiento BLE para llaves de seguridad, mientras que iOS prefiere NFC, lo que lleva a falsos negativos. Además, la falta de verificación estructurada de la atestación significó que no podíamos distinguir entre un YubiKey genuino y un clon de firmware comprometido que devolvía cadenas de certificado X.509 inválidas o valores de AAGUID incorrectos.
La tercera solución implementó un régimen de pruebas de matriz de autenticadores estructurado con dispositivos físicos, donde catalogamos las capacidades de cada autenticador (soporte de clave residente, formato de atestación, tipos de transporte) y ejecutamos manualmente ceremonias a través de combinaciones de navegadores y sistemas operativos. Interceptamos el tráfico con Burp Suite y las herramientas de desarrollo del navegador para inspeccionar el clientDataJSON y el attestationObject, probando escenarios de origen cruzado al incrustar el flujo de registro en iframes con diferentes atributos allow y verificando el comportamiento de clave residente configurando requireResidentKey: true y tratando de autenticar con un arreglo allowCredentials vacío.
Solución elegida y resultado
Seleccionamos el enfoque de matriz estructurada porque el comportamiento de WebAuthn está fundamentalmente ligado a la implementación de hardware y a las políticas de seguridad del navegador que los entornos virtuales no pueden emular. Esta metodología reveló que Safari requiere explícitamente atributos allow="publickey-credentials-get" para iframes de origen cruzado, que Chrome infiere automáticamente, causando las fallas silenciosas en la integración de Epic. Además, descubrimos que YubiKey 5 NFC devuelve transports: ["nfc", "usb"] pero iOS Safari solo enumera nfc durante la ceremonia, provocando que el filtro allowCredentials del lado del servidor rechace la credencial cuando la validación de transporte se impuso estrictamente. Después de relajar la validación de transporte en el servidor para aceptar cualquier transporte anunciado por el autenticador y agregar verificaciones de permisos de iframe a nuestra lista de verificación de pruebas manuales, la autenticación entre dispositivos tuvo éxito de manera consistente en el ecosistema de dispositivos mezclados del hospital.
¿Cómo verificas manualmente la integridad criptográfica de un objeto de atestación para garantizar que el autenticador sea genuino y no un firmware comprometido o un emulador durante las pruebas de caja negra?
Muchos candidatos asumen que la verificación de atestación es puramente una preocupación del lado del servidor. Para validar manualmente, extrae el attestationObject de la respuesta PublicKeyCredential del navegador (decodificar de base64url a binario), analízalo con un depurador CBOR (como cbor.me), e inspecciona el campo fmt. Para la atestación packed, verifica la cadena de certificados X.509 contra el Servicio de Metadatos de la Alianza FIDO (MDS) para verificar autenticadores revocados o banderas de auto-atestación. Para la atestación tpm, valida que el certificado TPM incluya la EK (Clave de Respaldación) y que la estructura certInfo coincida con el algoritmo de hash esperado. Esta inspección manual detecta autenticadores que devuelven firmas mal formadas o valores incorrectos de AAGUID que los scripts automatizados podrían pasar por alto si omiten la verificación estricta de atestación.
¿Cuál es la distinción precisa entre la Presencia del Usuario (UP) y la Verificación del Usuario (UV), y cómo impacta esto en la prueba de claves residentes (credenciales descubribles) entre autenticadores de plataforma y móviles?
Los candidatos a menudo confunden el simple toque en un YubiKey (UP) con la entrada de PIN (UV). En las pruebas manuales, debes verificar que al establecer userVerification: "discouraged" aún se permite el registro en un YubiKey (que solo realiza UP), pero al establecer residentKey: "required" se obliga a UV en la mayoría de autenticadores porque las claves residentes requieren protección. Los testers pasan por alto que Windows Hello siempre realiza UV (biométrico o PIN) incluso cuando se desaconseja, mientras que macOS Touch ID respeta la bandera pero falla en la creación de claves residentes sin UV. Debes probar manualmente la ceremonia con claves residentes required y preferred, observando si el autenticador devuelve un credentialId durante la autenticación sin allowCredentials (demostrando que era residente), y verificando el byte de banderas de authenticatorData (bit 0 para UP, bit 2 para UV) utilizando un analizador CBOR para confirmar que el comportamiento del autenticador coincide con las opciones.
¿Cómo pruebas la funcionalidad excludeCredentials para prevenir registros duplicados cuando solo tienes una clave de seguridad física, asegurando que el autenticador identifique correctamente las credenciales existentes?
Esto prueba la comprensión del mecanismo de descubrimiento del lado del cliente. Registra manualmente una credencial, captura el rawId, luego inicia una nueva ceremonia de registro con excludeCredentials que contenga esa ID y el mismo user.id. Un autenticador compatible debería devolver una DOMException llamada InvalidStateError. Sin embargo, los candidatos pasan por alto que Windows Hello y algunos Android keystores pueden devolver la credencial existente en lugar de un error (lo cual es válido según la especificación de WebAuthn Nivel 2 si el autenticador no soporta listas de exclusión). Debes verificar ambos resultados: que el servidor maneje el error de manera elegante, y que si se devuelve una credencial, coincida con la ID excluida y sea rechazada del lado del servidor. Además, prueba con un user.id diferente para asegurarte de que el autenticador no excluya incorrectamente credenciales de diferentes cuentas de usuario, lo que indicaría una grave vulnerabilidad de privacidad.