Autenticación web

La autenticación web ( WebAuthn ) es un estándar web publicado por el Consorcio World Wide Web (W3C). ^{[ 1 ] [ 2 ] [ 3 ]} Define una API que los sitios web utilizan para autenticarse con credenciales WebAuthn ( claves de acceso ^{[ 4 ] [ 5 ]} ) y describe lo que deben hacer los autenticadores WebAuthn. Resuelve muchos de los problemas de la autenticación tradicional basada en contraseñas al verificar la identidad del usuario con firmas digitales . ^{[ 6 ]} Aunque WebAuthn se suele promocionar como un reemplazo completo de las contraseñas, la mayoría de los sitios web que lo implementan siguen utilizando contraseñas de alguna manera. ^{[ 7 ]}

Para usar WebAuthn, los usuarios necesitan un autenticador compatible. El estándar no especifica cómo almacenar las claves necesarias para la firma, por lo que se pueden usar varios tipos de autenticadores. El tipo de autenticador más común es el autenticador de plataforma, que está integrado en el sistema operativo del dispositivo. Los autenticadores de plataforma comunes incluyen Android , Apple Keychain y Windows Hello . Estos utilizan funciones de seguridad de hardware (como TEE y TPM ) y, a menudo, sincronizan las credenciales entre dispositivos para facilitar su uso. Otro tipo de autenticador común es el autenticador itinerante, donde un dispositivo de hardware independiente autentica al usuario conectándose a través de USB , Bluetooth Low Energy o comunicaciones de campo cercano (NFC). La mayoría de los teléfonos inteligentes se pueden usar como autenticadores itinerantes, y también se utilizan claves de seguridad físicas dedicadas. WebAuthn es efectivamente compatible con versiones anteriores de FIDO Universal 2nd Factor (U2F), ya que ambos usan el protocolo CTAP . ^{[ 8 ]} Los administradores de contraseñas también se pueden usar como autenticadores, a menudo con sincronización en la nube. ^{[ 9 ]} Cuando la sincronización de credenciales no es viable o posible, se puede utilizar WebAuthn Hybrid Transport para acceder a las credenciales almacenadas en otro autenticador, como un teléfono inteligente. ^{[ 10 ]}

Al igual que el U2F tradicional, WebAuthn es resistente a algunos ataques de phishing ^{[ 11 ]} , ya que el autenticador solo ofrece credenciales registradas en el mismo sitio web . Sin embargo, a diferencia de U2F, WebAuthn puede implementarse sin contraseña ^{[ 12 ]} . Además, un autenticador de hardware itinerante resiste el malware, puesto que las claves se almacenan en un dispositivo independiente, lo que impide que el malware acceda a ellas directamente.

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 ] [ 13 ] [ 14 ]} Una especificación de nivel 3 es actualmente un Primer Borrador Público de Trabajo (FPWD). ^{[ 15 ]} WebAuthn es un componente central del Proyecto FIDO2 bajo la dirección de la Alianza FIDO . ^{[ 16 ]}

FIDO2 es el sucesor de FIDO Universal 2nd Factor (U2F). Mientras que U2F solo admite el modo multifactor, ya que fue diseñado para fortalecer los flujos de inicio de sesión existentes basados ​​en nombre de usuario/contraseña, FIDO2 agrega soporte para 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 . ^{[ 17 ]} Dependiendo de las capacidades del autenticador, esto puede ser: ^{[ 18 ]}

• algo que sabes: un secreto como un PIN , un código de acceso o un patrón de deslizamiento.
• algo que eres: un dato biométrico como la huella dactilar, el rostro , el iris o la voz.

Independientemente del modo, el autenticador nunca comparte sus secretos ni datos biométricos con el sitio web. ^{[ 19 ]} Además, un único secreto o dato biométrico de usuario funciona con todos los sitios web, ya que el autenticador selecciona el material de clave criptográfica correcto para usar con el servicio que solicita la autenticación una vez que la verificación del usuario se ha completado con éxito.

Se puede usar un secreto y un dato biométrico en el autenticador de forma conjunta, de manera similar a como se usarían en un teléfono inteligente . Por ejemplo, la huella dactilar proporciona un acceso cómodo al teléfono inteligente del usuario, pero en ocasiones el acceso mediante huella dactilar falla, en cuyo caso el usuario puede usar un PIN.

El W3C diseñó y estandarizó WebAuthn para resolver o mitigar muchos problemas inherentes a la autenticación tradicional basada en contraseñas:

• Generación y almacenamiento seguros de credenciales: WebAuthn genera credenciales únicas para cada sitio web mediante algoritmos robustos y las almacena de forma segura en autenticadores de confianza. Esto elimina vulnerabilidades comunes como:
  • Contraseñas débiles que pueden ser fácilmente descifradas mediante fuerza bruta debido a su longitud insuficiente.
  • Contraseñas predecibles vulnerables a ataques de diccionario (por ejemplo, "password", "12345678").
  • Contraseñas fáciles de adivinar basadas en información personal (por ejemplo, fechas de nacimiento, direcciones).
  • Almacenamiento deficiente de contraseñas en el lado del cliente (por ejemplo, anotadas o almacenadas en los contactos del teléfono).
  • Se puede reutilizar la contraseña en varios sitios web, ya que las credenciales de WebAuthn están diseñadas para ser específicas de cada sitio web.
  • Requisitos de contraseña inadecuados impuestos por el servidor (por ejemplo, criterios demasiado laxos o restrictivos, límites de longitud máxima arbitrarios, conjuntos de caracteres limitados).
  • Restricciones que impiden el uso de las funciones de autocompletado del gestor de contraseñas.
• Sin almacenamiento de credenciales en el servidor: La parte privada de una credencial nunca se almacena en un servidor, lo que elimina riesgos y vulnerabilidades como:
  • Almacenamiento inseguro de contraseñas en bases de datos (por ejemplo, en texto plano o utilizando algoritmos/estructuras débiles basados ​​en funciones hash).
  • Filtraciones de bases de datos que exponen contraseñas.
  • Cambios periódicos de contraseña obligatorios e ineficaces.
• Credenciales únicas para cada sitio web: WebAuthn garantiza que las credenciales sean únicas para cada sitio web, eliminando los siguientes riesgos y vulnerabilidades:
  • Los ataques de relleno de credenciales consisten en que los atacantes utilizan las credenciales de una filtración de datos en varios sitios web.
  • Los ataques de phishing son efectivos, ya que las credenciales no se pueden reutilizar ni aplicar incorrectamente en diferentes sitios web.

Passkey es el término no técnico de facto para una credencial WebAuthn. ^{[ 5 ] [ 6 ]} La mayoría de las interfaces de usuario que admiten WebAuthn usan solo passkey para referirse a las credenciales WebAuthn. ^{[ 7 ]}

Cuando Apple presentó por primera vez las claves de acceso al público en 2022, ^{[ 20 ]} hizo hincapié en sus integraciones de plataforma de primera parte. Esto, combinado con la falta de comunicación clara por parte de otros líderes de la industria, llevó a algunos a especular que las claves de acceso eran propiedad de Apple, lo cual no era el caso. ^{[ 21 ]} A medida que los navegadores y sitios web comenzaron a implementar WebAuthn, los conjuntos de características inconsistentes dieron como resultado una variedad de interpretaciones de lo que exactamente se consideraba una clave de acceso. Algunas personas asumieron que una clave de acceso requería administración por parte de un autenticador de plataforma, o necesitaba sincronización mediante la nube. Una mejor definición es que una clave de acceso es cualquier credencial WebAuthn administrada por cualquier autenticador WebAuthn. ^{[ 5 ]} Esta definición cubre la mayor parte de lo que diferentes proveedores denominan y aceptan como claves de acceso .

Al igual que su predecesor FIDO U2F, la autenticación web del W3C (WebAuthn) implica un sitio web , un navegador web y un autenticador: ^{[ 1 ]}

• El sitio web es un proveedor de confianza WebAuthn que cumple con los requisitos.
• El navegador es un cliente WebAuthn compatible.
• El autenticador es un autenticador FIDO2, es decir, se asume que es compatible con el cliente WebAuthn.

WebAuthn especifica cómo un reclamante demuestra la posesión y el control de un autenticador FIDO2 ante un verificador denominado Parte Confiable de WebAuthn. El proceso de autenticación está mediado por una entidad llamada Cliente WebAuthn, que no es más que un navegador web compatible.

Autenticación

El autenticador es un autenticador criptográfico multifactor que utiliza criptografía de clave pública para firmar una aserción de autenticación dirigida a la parte confiable de WebAuthn. Suponiendo que el autenticador utilice reconocimiento facial , huella dactilar o PIN para la verificación del usuario, el autenticador en sí es algo que usted posee, mientras que el reconocimiento facial y la huella dactilar (biométricos) son algo que usted es , y el PIN es algo que usted sabe .

Para iniciar el flujo de autenticación WebAuthn, ^{[ 22 ]} la parte confiable de WebAuthn indica sus intenciones al cliente WebAuthn (es decir, el navegador) mediante JavaScript . El cliente WebAuthn se comunica con el autenticador mediante una API de JavaScript implementada en el navegador. Un autenticador itinerante cumple con el protocolo FIDO Cliente a Autenticador (CTAP), ^{[ 23 ]} y se conecta mediante USB , Bluetooth de bajo consumo o comunicaciones de campo cercano (NFC).

WebAuthn no requiere estrictamente un autenticador de hardware itinerante. Como alternativa, 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). Algunos ejemplos relevantes de autenticadores de plataforma son Windows Hello ^{[ 24 ]} y el sistema operativo Android ^{[ 25 ]} .

WebAuthn Hybrid Transport permite que el cliente WebAuthn acceda a las credenciales almacenadas en otro autenticador, como un teléfono inteligente, lo cual resulta útil en ciertas situaciones donde la sincronización de credenciales no es viable. ^{[ 10 ]}

Persiste la idea errónea 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 cual no es cierto. ^{[ 26 ] [ 27 ]}

El estándar WebAuthn Nivel  1 fue publicado como una Recomendación del W3C por el Grupo de Trabajo de Autenticación Web el 4 de marzo de 2019. ^{[ 1 ] [ 13 ] [ 31 ]} WebAuthn es compatible con Google Chrome , Mozilla Firefox , Microsoft Edge , Apple Safari ^{[ 13 ]} y Opera . ^{[ 32 ]}

La versión de escritorio de Google Chrome ha sido compatible con WebAuthn desde la versión 67. ^{[ 33 ]} Firefox, que no había sido totalmente compatible con el estándar FIDO U2F anterior, incluyó y habilitó WebAuthn en la versión 60 de Firefox, lanzada el 9 de mayo de 2018. ^{[ 34 ]} Una versión temprana de Windows Insider de Microsoft Edge (Build 17682) implementó una versión de WebAuthn que funciona tanto con Windows Hello como con claves de seguridad externas. ^{[ 35 ]}

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 único de "manejador de usuario" por cuenta, que los autenticadores más antiguos no pueden almacenar. ^{[ 1 ]}

Uno de los primeros autenticadores compatibles con FIDO2 fue la Security Key de segunda generación de Yubico, anunciada el 10 de abril de 2018. ^{[ 36 ]} El primer autenticador compatible con FIDO2 con pantalla fue el Trezor Model T de SatoshiLabs, anunciado el 6 de noviembre de 2019. ^{[ 37 ]} El Trezor Model T también fue el primer autenticador que permitió a los usuarios seleccionar qué credencial residente de FIDO2 se debía usar directamente en un dispositivo.

La primera clave FIDO2 con certificación de Nivel de Seguridad 2, llamada "Goldengate", fue anunciada un año después por eWBM el 8 de abril de 2019. ^{[ 38 ] [ 39 ]}

Dropbox anunció el soporte para inicios de sesión WebAuthn (como segundo factor) el 8 de mayo de 2018. ^{[ 40 ]}

Apple anunció el 24 de junio de 2020 que Face ID o Touch ID podrían usarse como autenticador de plataforma WebAuthn con Safari. ^{[ 41 ]}

Varios gestores de contraseñas como Bitwarden y Dashlane admiten WebAuthn. ^{[ 42 ] [ 43 ]}

WebAuthn implementa una extensión de la API de administración de credenciales más general del W3C , que busca formalizar la interacción entre sitios web y navegadores web al intercambiar credenciales de usuario. La API de autenticación web ^{[ 44 ] [ 45 ]} 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 su asociación con cuentas de usuario (posiblemente al crear la cuenta inicialmente, pero más probablemente al agregar un nuevo dispositivo de seguridad a una cuenta existente), mientras que el método se utiliza para autenticar (por ejemplo, al iniciar sesión).navigator.credentials.create()navigator.credentials.get()publicKeycreate()get()

Para comprobar si un navegador admite WebAuthn, los scripts deben verificar 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 las 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 encontraron ninguna vulnerabilidad específica , sí revelaron algunas debilidades importantes en la forma en que se utiliza la criptografía subyacente y en cómo la exige el estándar. ^{[ 46 ]}

Los principales puntos de crítica giran en torno a dos problemas potenciales que resultaron problemáticos en otros sistemas criptográficos en el pasado y que, por lo tanto, deben evitarse para no ser víctimas del mismo tipo de ataques:

• Mediante el uso obligatorio de COSE ( RFC  8152 ), WebAuthn también admite RSA con relleno PKCS1v1.5 . Se sabe desde hace al menos veinte años que este esquema de relleno es vulnerable a ataques específicos , y en el pasado se ha logrado explotarlo en otros protocolos e implementaciones del criptosistema RSA. Si bien es difícil explotarlo en las condiciones dadas en el contexto de WebAuthn, dado que existen primitivas criptográficas y esquemas de relleno más seguros, sigue siendo una mala elección y los criptógrafos ya no lo consideran la mejor práctica.
• La Alianza FIDO estandarizó el esquema criptográfico asimétrico ECDAA . ^{[ 47 ]} Esta es una versión de la atestación anónima directa basada en curvas elípticas y, en el caso de WebAuthn, se utiliza para verificar la integridad de los autenticadores, preservando al mismo tiempo la privacidad de los usuarios, ya que no permite la correlación global de identificadores. Sin embargo, ECDAA no incorpora algunas de las lecciones aprendidas en las últimas décadas de investigación en el área de la criptografía de curva elíptica , ya que la curva elegida presenta ciertas deficiencias de seguridad inherentes a este tipo de curva, lo que reduce sustancialmente las garantías de seguridad. Además, el estándar ECDAA implica firmas aleatorias y no deterministas, lo que ya ha sido un problema en el pasado.

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 solicitó la opinión ni los comentarios de criptógrafos experimentados. Por lo tanto, el estándar no fue sometido a una amplia investigación criptográfica por parte del ámbito académico.

A pesar de estas deficiencias, Paragon Initiative Enterprises sigue animando a los usuarios a continuar utilizando WebAuthn, pero ha formulado algunas recomendaciones para los posibles implementadores y desarrolladores del estándar, con la esperanza de que puedan implementarse antes de su finalización. Evitar estos errores cuanto antes protegería al sector de los problemas derivados de estándares defectuosos y de la necesidad de compatibilidad con versiones anteriores .

ECDAA se diseñó únicamente para usarse en combinación con la atestación del dispositivo. 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 atestación durante el proceso de registro. De forma independiente, las partes confiables pueden optar por requerir o no la atestación. ECDAA se eliminó de WebAuthn Nivel 2, ya que no estaba implementado ni por los navegadores ni por las partes confiables. ^{[ 48 ]}

WebAuthn, conocido popularmente como "passkeys", ha recibido reacciones encontradas por parte del público:

• Troy Hunt : "Las contraseñas son uno de los pocos mecanismos de seguridad que facilitan la vida, en lugar de complicarla." ^{[ 49 ]} "Es un inicio de sesión con un solo clic, y al hacer clic en el botón morado obtengo acceso inmediato a mi cuenta." ^{[ 49 ]}
• Dan Goodin: "La tecnología de clave de acceso es elegante, pero definitivamente no es una seguridad práctica." ^{[ 7 ]}
• Bruce Davie : "...la implementación parece no haber superado la prueba de 'facilitar el uso a los usuarios', que en mi opinión es la esencia de las claves de acceso. Llevo más de 30 años utilizando criptografía de clave pública ... Si a mí me resulta confuso usar claves de acceso, no es un buen augurio para los usuarios más comunes." ^{[ 50 ]}

• Alianza FIDO
• generador de claves ssh

• Autenticación web: una API para acceder a credenciales de clave pública.
• Grupo de trabajo sobre autenticación web
• API de autenticación web en MDN
• Autenticación web impresionante
• Documentación de GitHub: Acerca de las claves de acceso
• Adam Langley: Un recorrido por WebAuthn