Web Authentication ( WebAuthn ) es un estándar web publicado por el World Wide Web Consortium (W3C). [1] [2] [3] WebAuthn es un componente central del Proyecto FIDO2 bajo la guía de la FIDO Alliance . [4] El objetivo del proyecto es estandarizar una interfaz para autenticar usuarios en aplicaciones y servicios basados en la web utilizando criptografía de clave pública . Las credenciales WebAuthn (que son en sí mismas credenciales FIDO) que están disponibles en varios dispositivos se conocen comúnmente como claves de acceso . [5]
En el lado del cliente, la compatibilidad con WebAuthn se puede implementar de diversas maneras. Las operaciones criptográficas subyacentes las realiza un autenticador , que es un modelo funcional abstracto que es mayormente agnóstico con respecto a cómo se administra el material de claves. Esto hace posible implementar la compatibilidad con WebAuthn puramente en software, haciendo uso del entorno de ejecución confiable de un procesador o un Módulo de plataforma confiable (TPM). Las operaciones criptográficas sensibles también se pueden descargar a un autenticador de hardware itinerante al que se puede acceder a su vez a través de USB , Bluetooth Low Energy o comunicaciones de campo cercano (NFC). Un autenticador de hardware itinerante cumple con el Protocolo de cliente a autenticador FIDO (CTAP), [6] lo que hace que WebAuthn sea efectivamente compatible con versiones anteriores del estándar FIDO Universal 2nd Factor (U2F). [7]
Al igual que el U2F tradicional, la autenticación web es resistente a la suplantación de identidad del verificador; es decir, es resistente a los ataques de phishing, [8] pero a diferencia de U2F, WebAuthn no requiere una contraseña tradicional. [9] Además, un autenticador de hardware móvil es resistente al malware ya que el material de la clave privada no es accesible en ningún momento para el software que se ejecuta en la máquina host.
Los estándares WebAuthn de nivel 1 y 2 se publicaron como recomendaciones del W3C el 4 de marzo de 2019 y el 8 de abril de 2021 respectivamente. [1] [10] [11] Una especificación de nivel 3 es actualmente un primer borrador de trabajo público (FPWD). [12]
FIDO2 es el sucesor de FIDO Universal 2nd Factor (U2F). Mientras que U2F solo admite el modo multifactor, ya que se diseñó para fortalecer los flujos de inicio de sesión basados en nombre de usuario y contraseña existentes, FIDO2 agrega compatibilidad con el modo de factor único. En el modo multifactor, el autenticador se activa mediante una prueba de presencia del usuario , que generalmente consiste en presionar un botón; no se requiere contraseña. En el modo de factor único, el autenticador ( algo que usted tiene ) realiza la verificación del usuario . [13] Dependiendo de las capacidades del autenticador, esto puede ser: [14]
Independientemente del modo, el autenticador nunca comparte sus secretos o datos biométricos con el sitio web. [15] Además, el secreto o la biometría de un solo usuario funciona con todos los sitios web, ya que el autenticador seleccionará el material de clave criptográfica correcto para usar en el servicio que solicita la autenticación después de que la verificación del usuario se haya completado con éxito.
Se pueden usar juntos un secreto y un dato biométrico en el autenticador, de manera similar a como se usarían en un teléfono inteligente . Por ejemplo, se usa una huella digital para brindar un acceso conveniente a su teléfono inteligente, pero en ocasiones el acceso con huella digital falla, en cuyo caso se puede usar un PIN.
WebAuthn aborda por diseño muchos problemas inherentes a la autenticación tradicional basada en contraseña:
Al igual que su predecesor FIDO U2F, la autenticación web W3C (WebAuthn) involucra un sitio web , un navegador web y un autenticador: [1]
WebAuthn especifica cómo un solicitante demuestra la posesión y el control de un autenticador FIDO2 a un verificador llamado Parte Confiable de WebAuthn. El proceso de autenticación está mediado por una entidad llamada Cliente de WebAuthn, que es poco más que un navegador web compatible.
A modo de ejemplo, suponemos que el autenticador es un autenticador de hardware móvil (consulte a continuación otras opciones). En cualquier caso, el autenticador es un autenticador criptográfico multifactor que utiliza criptografía de clave pública para firmar una afirmación de autenticación dirigida a la parte que confía en WebAuthn. Suponiendo que el autenticador utiliza un PIN para la verificación del usuario, el autenticador en sí es algo que usted tiene , mientras que el PIN es algo que usted sabe .
Para iniciar el flujo de autenticación de WebAuthn, [16] la Parte Confiable de WebAuthn indica sus intenciones al Cliente de WebAuthn (es decir, el navegador) a través de JavaScript . El Cliente de WebAuthn se comunica con el autenticador mediante una API de JavaScript implementada en el navegador. Un autenticador itinerante cumple con el Protocolo de Cliente a Autenticador FIDO .
WebAuthn no requiere estrictamente un autenticador de hardware móvil. Alternativamente, se puede utilizar un autenticador de software (por ejemplo, implementado en un teléfono inteligente) o un autenticador de plataforma (es decir, un autenticador implementado directamente en el dispositivo cliente de WebAuthn). Ejemplos relevantes de autenticadores de plataforma incluyen Windows Hello [17] y el sistema operativo Android . [18]
El flujo ilustrado se basa en la verificación de usuario basada en PIN, que, en términos de usabilidad, es solo una mejora modesta con respecto a la autenticación de contraseña ordinaria. En la práctica, el uso de biometría para la verificación de usuario puede mejorar la usabilidad de WebAuthn. [ cita requerida ] Sin embargo, la logística detrás de la biometría aún no se comprende bien. Existe un malentendido persistente entre los usuarios de que los datos biométricos se transmiten a través de la red de la misma manera que las contraseñas, lo que no es el caso. [19] [20]
Cuando la parte confiada de WebAuthn recibe la afirmación de autenticación firmada del navegador, la firma digital en la afirmación se verifica utilizando una clave pública confiable para el usuario.
Para obtener una clave pública para el usuario, la Parte Confiable de WebAuthn inicia un flujo de registro de WebAuthn [21] que es similar al flujo de autenticación ilustrado anteriormente. La principal diferencia es que el autenticador ahora firma una declaración de atestación con su clave privada de atestación. La declaración de atestación firmada contiene una copia de la clave pública que la Parte Confiable de WebAuthn utiliza en última instancia para verificar una afirmación de autenticación firmada. La declaración de atestación también contiene metadatos que describen al autenticador en sí. [ cita requerida ]
La firma digital en la declaración de certificación se verifica con la clave pública de certificación confiable para ese modelo particular de autenticador. No se especifica cómo la parte autenticada de WebAuthn obtiene su almacén de claves públicas de certificación confiables. Una opción es utilizar el servicio de metadatos FIDO. [22]
El tipo de certificación especificado en JavaScript determina el modelo de confianza. Por ejemplo, puede ser conveniente un tipo de certificación denominado autocertificación, cuyo modelo de confianza es básicamente la confianza en el primer uso .
El estándar WebAuthn Nivel 1 fue publicado como una Recomendación W3C por el Grupo de Trabajo de Autenticación Web el 4 de marzo de 2019. [1] [10] [23] WebAuthn es compatible con Google Chrome , Mozilla Firefox , Microsoft Edge , Apple Safari [10] y Opera . [24]
La versión de escritorio de Google Chrome ha sido compatible con WebAuthn desde la versión 67. [25] Firefox, que no era totalmente compatible con el estándar FIDO U2F anterior, incluyó y habilitó WebAuthn en Firefox versión 60, lanzada el 9 de mayo de 2018. [26] Una versión temprana de Windows Insider de Microsoft Edge (compilación 17682) implementó una versión de WebAuthn que funciona tanto con Windows Hello como con claves de seguridad externas. [27]
Las claves de seguridad FIDO U2F existentes son en gran medida compatibles con el estándar WebAuthn, aunque WebAuthn agregó la capacidad de hacer referencia a un identificador de "usuario" único por cuenta, que los autenticadores más antiguos no pueden almacenar. [1]
Uno de los primeros autenticadores compatibles con FIDO2 fue el Security Key de segunda generación de Yubico, anunciado el 10 de abril de 2018. [28] El primer autenticador compatible con FIDO2 con pantalla fue el Trezor Model T de SatoshiLabs, anunciado el 6 de noviembre de 2019. [29] El Trezor Model T también fue el primer autenticador que permitió a los usuarios seleccionar qué credencial de residente FIDO2 debía usarse directamente en un dispositivo.
La primera clave FIDO2 certificada con nivel de seguridad 2, denominada "Goldengate", fue anunciada un año después por eWBM el 8 de abril de 2019. [30] [31]
Dropbox anunció el soporte para inicios de sesión WebAuthn (como segundo factor) el 8 de mayo de 2018. [32]
Apple anunció que Face ID o Touch ID podrían usarse como autenticador de la plataforma WebAuthn con Safari el 24 de junio de 2020. [33]
WebAuthn implementa una extensión de la API de administración de credenciales más general del W3C , que es un intento de formalizar la interacción entre sitios web y navegadores web al intercambiar credenciales de usuario. La API de autenticación web [34] [35] extiende los métodos de administración de credenciales y JavaScript para que acepten un parámetro. El método se utiliza para registrar autenticadores de clave pública como parte de la asociación con cuentas de usuario (posiblemente en el momento de creación de la cuenta inicial, pero más probablemente al agregar un nuevo dispositivo de seguridad a una cuenta existente) mientras que el método se utiliza para la autenticación (como al iniciar sesión).navigator.credentials.create()navigator.credentials.get() publicKeycreate()get()
Para comprobar si un navegador admite WebAuthn, los scripts deben comprobar si la window.PublicKeyCredentialinterfaz está definida. Además de PublicKeyCredential, el estándar también define las interfaces AuthenticatorResponse, AuthenticatorAttestationResponsey , AuthenticatorAssertionResponseademás de una variedad de diccionarios y otros tipos de datos.
La API no permite el acceso directo ni la manipulación de claves privadas, más allá de solicitar su creación inicial.
En agosto de 2018, Paragon Initiative Enterprises realizó una auditoría de seguridad del estándar WebAuthn. Si bien no pudieron encontrar ninguna vulnerabilidad específica , revelaron algunas debilidades graves en la forma en que se utiliza la criptografía subyacente y en la que la norma la exige. [36]
Los principales puntos de crítica giran en torno a dos problemas potenciales que fueron problemáticos en otros sistemas criptográficos en el pasado y por lo tanto deberían evitarse para no ser víctimas de la misma clase de ataques:
Paragon Initiative Enterprises también criticó la forma en que se desarrolló inicialmente el estándar, ya que la propuesta no se hizo pública con antelación y no se pidió a los criptógrafos experimentados que dieran sugerencias y comentarios. Por lo tanto, el estándar no fue objeto de una amplia investigación criptográfica por parte del mundo académico.
A pesar de estas deficiencias, Paragon Initiative Enterprises sigue animando a los usuarios a seguir utilizando WebAuthn, pero ha elaborado algunas recomendaciones para posibles implementadores y desarrolladores del estándar que esperan que se puedan implementar antes de que el estándar esté finalizado. Evitar este tipo de errores lo antes posible protegería a la industria de cualquier desafío que se presente debido a estándares defectuosos y la necesidad de compatibilidad con versiones anteriores .
ECDAA fue diseñado únicamente para usarse en combinación con la certificación de dispositivos. Esta característica particular de WebAuthn no es necesariamente necesaria para que la autenticación funcione. Las implementaciones actuales permiten al usuario decidir si se envía una declaración de certificación durante la ceremonia de registro. De manera independiente, las partes que confían pueden elegir si requieren certificación o no. ECDAA fue eliminado de WebAuthn Nivel 2 ya que no fue implementado por los navegadores ni por las partes que confían. [38]