Clave residente de WebAuthn: credenciales descubribles como passkeys

Las passkeys y el protocolo subyacente WebAuthn están revolucionando el panorama de la autenticación. Sin embargo, configurar un servidor WebAuthn de la manera correcta puede ser una tarea complicada. Una configuración incorrecta no solo puede introducir vulnerabilidades, sino también inutilizar las passkeys existentes si necesitas cambiarlas más adelante. El siguiente artículo te ayudará a comprender mejor las especificaciones, a menudo complejas, de WebAuthn y te dará consejos sobre qué ajustes son los mejores para tu caso de uso.

WebAuthn opera con tres entidades principales:

• Relying Party (RP) o Parte de Confianza: Es tu servicio web que desea autenticar a un usuario. Envía desafíos al cliente, verifica las respuestas y gestiona la clave pública de una passkey.
• Autenticadores: Son dispositivos que pueden demostrar la posesión de una credencial. Algunos ejemplos son los smartphones, los portátiles o las llaves de seguridad (por ejemplo, YubiKeys). Los autenticadores pueden ser específicos de una plataforma (como Windows Hello o el Touch ID / Face ID de Apple) o multiplataforma (como las llaves de seguridad, por ejemplo, YubiKeys).
• Clientes: Normalmente, son navegadores web o aplicaciones nativas que actúan como intermediarios entre la RP y el autenticador. Facilitan la comunicación, asegurando que los datos fluyan de forma correcta y segura.

Want to try passkeys yourself in a passkeys demo?

Try Passkeys

A continuación, se describe el flujo de datos de alto nivel durante un proceso de autenticación (ya sea inicio de sesión o registro).

1. Inicio en el cliente: El proceso comienza en el lado del cliente, generalmente cuando un usuario intenta iniciar sesión o registrarse. Por ejemplo, podría hacer clic en un botón de "Iniciar sesión con WebAuthn" y el cliente envía una solicitud de un desafío a la RP.
2. Solicitud de la RP: La RP envía un desafío de vuelta al cliente. Este desafío es un valor generado aleatoriamente que garantiza la autenticidad de la respuesta posterior.
3. Del cliente al autenticador: Durante el registro, el cliente solicita al autenticador que cree una nueva passkey creando el par de claves pública-privada correspondiente. Durante el inicio de sesión, el cliente solicita al autenticador que firme el desafío. Esto se hace utilizando la clave privada en el autenticador, que corresponde a una clave pública previamente registrada y almacenada en la RP.
4. Respuesta del autenticador: Durante el registro, el autenticador envía la clave pública de vuelta al cliente. Durante el inicio de sesión, el autenticador firma el desafío y envía esta aserción firmada de vuelta al cliente.
5. Del cliente a la RP: El cliente reenvía esta nueva clave pública / la aserción firmada a la RP.
6. Verificación de la RP: La RP almacena la clave pública / verifica la aserción firmada utilizando la clave pública almacenada. Si es válida, la autenticación es exitosa.

Ben Gould

Head of Engineering

I’ve built hundreds of integrations in my time, including quite a few with identity providers and I’ve never been so impressed with a developer experience as I have been with Corbado.

Más de 10 000 desarrolladores confían en Corbado y hacen que Internet sea más seguro con passkeys. ¿Tienes preguntas? Hemos escrito más de 150 artículos de blog sobre passkeys.

Únete a la comunidad de Passkeys

El flujo de proceso de alto nivel descrito anteriormente detalla los procesos de registro e inicio de sesión de WebAuthn. Las passkeys se basan en WebAuthn. Originalmente, el término passkeys se usaba como un término más memorable y menos técnico que WebAuthn para describir lo mismo. Además, las passkeys ofrecen más funciones en comparación con el estándar WebAuthn, como la posibilidad de sincronizar passkeys a través de cuentas en la nube o gestores de contraseñas.

Para comprender mejor las siguientes secciones, definiremos algunos términos importantes en el protocolo WebAuthn para tener un entendimiento común.

• ID de credencial: El ID de credencial es un identificador único asignado a una credencial de clave pública específica generada por un autenticador. Permite a las Relying Parties (RPs) identificar y seleccionar la PublicKeyCredential correcta para los procesos de autenticación.
• PublicKeyCredential: Es la estructura de datos principal que devuelve la API de WebAuthn del navegador o de las aplicaciones nativas. Engloba tanto los datos de atestación durante el registro como los datos de aserción durante el inicio de sesión. Esencialmente, contiene los datos que la RP necesita para verificar el proceso.
• Atestación: La atestación en el contexto de WebAuthn sirve como prueba del origen y la integridad del autenticador. Durante el registro, es una forma de que el autenticador diga: "He registrado de forma segura la credencial del usuario, y aquí tienes una declaración que puedes usar para verificarlo". La Relying Party puede entonces verificar que la firma proviene de un autenticador específico que está permitido (por ejemplo, Yubikey). No todos los autenticadores de passkeys responden con tal atestación, algunos simplemente no envían datos útiles (consulta aquí la lista de autenticadores de passkeys). Se pueden encontrar más AAGUIDs (Authenticator Attestation GUIDs), que identifican más autenticadores (principalmente llaves de seguridad, por ejemplo, YubiKeys), en el Servicio de Metadatos de la Alianza FIDO.
• Aserción: Después del proceso de registro, cuando un usuario intenta iniciar sesión, el autenticador produce una aserción. La aserción es básicamente la PublicKeyCredential + el desafío firmado. Esta aserción demuestra que el usuario posee la clave privada vinculada a la clave pública registrada sin revelar la clave privada real. Es la forma que tiene el autenticador de decir: "Este es el usuario genuino, y puedo dar fe de ello".

Subscribe to our Passkeys Substack for the latest news.

Subscribe

Las claves residentes (RKs) y las claves no residentes (NRKs) son dos tipos de claves criptográficas utilizadas en el protocolo WebAuthn, y se diferencian principalmente en su ubicación de almacenamiento y mecanismo de recuperación.

Definición:

Las claves residentes se almacenan directamente en el propio autenticador. Este podría ser una llave de seguridad (por ejemplo, YubiKey), un enclave seguro de la plataforma (por ejemplo, el Secure Enclave del iPhone) o un módulo de plataforma segura (TPM) en un portátil. La IU condicional (autorrelleno de passkeys) solo funciona con claves residentes y el grupo de trabajo de WebAuthn actualmente requiere que las claves residentes se consideren como una passkey.

En la siguiente captura de pantalla, se ve una lista de todas las claves residentes (ID de credencial, rpID, nombre de usuario, nombre para mostrar) que están almacenadas en una YubiKey. Las claves no residentes no están en la lista, ya que no se almacenan en el autenticador:

Flujo de inicio de sesión:

Fuente: William Brown

Durante el proceso de inicio de sesión, la Relying Party envía una solicitud sin especificar credenciales al cliente (navegador), que comienza a consultar al autenticador (en el gráfico: llave de seguridad). El autenticador descubre todas las claves residentes para la Relying Party correspondiente y el cliente (navegador) selecciona la clave residente deseada. Esta clave residente se utiliza para firmar el desafío. La firma se envía desde el autenticador a través del cliente a la Relying Party.

Ventajas:

1. Experiencia de usuario optimizada: Una de las ventajas más significativas de las claves residentes es que el autenticador almacena el user handle (por ejemplo, correo electrónico, número de teléfono, nombre de usuario) y, por lo tanto, puede rellenar previamente el user handle (por ejemplo, correo electrónico, número de teléfono, nombre de usuario) para el inicio de sesión. Los usuarios no necesitan recordar o introducir user handles (por ejemplo, correo electrónico, número de teléfono, nombre de usuario), lo que agiliza el proceso de inicio de sesión, especialmente en dispositivos con capacidades biométricas. Esto también puede ocurrir automáticamente con la IU condicional.
2. Autenticación específica del dispositivo: Las claves residentes pueden proporcionar una capa adicional de seguridad al vincular la autenticación a un dispositivo específico. Esto puede ser particularmente útil para servicios que desean asegurarse de que los usuarios inicien sesión desde dispositivos de confianza.
3. IU condicional (autorrelleno de passkeys): La IU condicional solo funciona con claves residentes, proporcionando la experiencia de inicio de sesión más fluida (ver más abajo para más detalles).

Desventajas:

1. Limitación de almacenamiento: Algunos autenticadores tienen una capacidad de almacenamiento finita. Especialmente en el caso de las llaves de seguridad (por ejemplo, YubiKeys), a menudo hay un límite en el número de claves residentes que pueden almacenar (la mayoría tiene un límite que va de 8 a ~100 claves residentes). Una vez que se alcanza este límite, es posible que sea necesario eliminar claves antiguas para hacer espacio para las nuevas, o que el usuario deba usar otro autenticador.
2. Pérdida del autenticador: Si el autenticador, por ejemplo, una llave de seguridad (por ejemplo, YubiKey) o un smartphone, se pierde o se daña, todas las claves residentes en ese dispositivo se pierden. Esto podría bloquear el acceso de los usuarios a múltiples servicios hasta que vuelvan a registrarse o recuperen sus cuentas. Sincronizar las claves a través de una cuenta en la nube (por ejemplo, Llavero de iCloud, Administrador de contraseñas de Google) o un gestor de contraseñas moderno (por ejemplo, 1Password o Dashlane) evita esta pérdida.
3. Preocupaciones de seguridad: Si se roba un autenticador con claves residentes, un atacante podría intentar extraer las claves. Aunque los autenticadores modernos tienen mecanismos de seguridad robustos para evitar la extracción, por ejemplo, el usuario protege el dispositivo con un PIN, código de acceso o gesto fuerte, el riesgo, aunque mínimo, todavía existe.

Casos de uso: Ideal para dispositivos donde el usuario se autentica con frecuencia, como smartphones o portátiles personales.

Want to find out how many people use passkeys?

View Adoption Data

Definición:

Las claves no residentes, en cambio, no se almacenan en el autenticador. En su lugar, el autenticador genera un nuevo par de claves (basado en su clave maestra protegida internamente) y envía la clave pública de este nuevo par de claves al servidor (Relying Party) junto con el ID de credencial (que contiene una semilla) durante el registro. El servidor asocia entonces esta clave pública con la cuenta del usuario. Para autenticaciones posteriores, el autenticador vuelve a derivar la clave privada al recibir el ID de credencial, extrayendo la semilla y combinándola con la clave maestra. Debido a que la clave solo está disponible temporalmente en la memoria protegida del autenticador, a veces se le llama clave efímera en el lenguaje criptográfico.

Flujo de inicio de sesión:

Fuente: William Brown

Durante el proceso de inicio de sesión, la Relying Party primero debe identificar qué usuario está solicitando la autenticación (por ejemplo, pidiendo un user handle, como correo electrónico, número de teléfono o nombre de usuario) y luego envía los ID de credencial que conoce para el usuario solicitante al cliente (navegador). El cliente los reenvía al autenticador (aquí: llave de seguridad). El autenticador utiliza el ID de la credencial junto con la clave maestra del autenticador para derivar la clave privada temporal, firma el desafío con la clave generada y la devuelve al cliente (aquí: navegador), que la reenvía a la Relying Party. Las claves no residentes se usaban originalmente como segundo factor antes de la introducción de las passkeys. Por lo tanto, identificar primero al usuario era parte del proceso de inicio de sesión regular.

Ventajas:

1. Escalabilidad: Dado que las claves no residentes no residen en el autenticador, los usuarios pueden tener un número casi ilimitado de claves no residentes asociadas con varios servicios. Esto es particularmente beneficioso para los usuarios que tienen cuentas en numerosas plataformas.
2. Capacidad de roaming: Las claves no residentes son ideales para autenticadores itinerantes como las llaves de seguridad (por ejemplo, YubiKey). Un usuario puede usar la misma llave de seguridad (por ejemplo, YubiKey) para autenticarse en múltiples dispositivos y plataformas, proporcionando una experiencia consistente.
3. Menor dependencia del almacenamiento del autenticador: Con la configuración adecuada del servidor WebAuthn, no hay necesidad de preocuparse por las limitaciones de almacenamiento del autenticador. Esto puede ser particularmente ventajoso para autenticadores de bajo almacenamiento, como las llaves de seguridad (por ejemplo, YubiKeys).

Desventajas:

1. Menos UX ya que se requiere el User Handle: La mayor desventaja de las claves no residentes es que el user handle (por ejemplo, correo electrónico, número de teléfono, nombre de usuario) debe ser proporcionado por el usuario, lo que hace imposible un autorrelleno de nombre de usuario a través de la IU condicional. Este user handle debe estar vinculado al ID de credencial que se necesita para calcular la clave efímera encapsulada.
2. Potencial de mala gestión: Las RPs necesitan gestionar y asegurar las asociaciones entre las cuentas de usuario y las claves públicas. Una mala gestión o vulnerabilidades podrían conducir a problemas de seguridad.

Casos de uso: Ideal para autenticadores itinerantes como las llaves de seguridad (por ejemplo, YubiKeys) que se utilizan en múltiples servicios o plataformas.

Imagina que tienes una llave de seguridad (por ejemplo, YubiKey) y la registras en dos servicios en línea: Servicio A y Servicio B. Para el Servicio A, usas una clave residente. Para el Servicio B, una clave no residente. Cuando te autenticas en el Servicio A, simplemente tocas tu llave de seguridad (por ejemplo, YubiKey) y ya estás dentro, sin necesidad de especificar un nombre de usuario. Para el Servicio B, primero proporcionarías tu nombre de usuario en el navegador / aplicación nativa. El servicio envía entonces el ID de credencial asociado a tu llave de seguridad (por ejemplo, YubiKey), que luego regenera la clave privada efímera para la autenticación.

En esencia, aunque tanto las claves residentes como las no residentes mejoran la seguridad al aprovechar la autenticación criptográfica, sus experiencias de usuario y mecanismos de almacenamiento difieren, atendiendo a casos de uso variados.

Want to experiment with passkey flows? Try our Passkeys Debugger.

Try for Free

La IU condicional es una característica fundamental de las passkeys / WebAuthn. Simplifica aún más las cosas para el usuario, ya que este no solo no necesita recordar una contraseña, sino que tampoco necesita recordar el user handle (por ejemplo, correo electrónico, número de teléfono, nombre de usuario) con el que se registró en una Relying Party. Especialmente en casos donde los servicios de las Relying Parties se usan solo ocasionalmente, este es un gran paso.

Esto funciona porque tan pronto como se abre la página de inicio de sesión, el servidor de la Relying Party envía un desafío en segundo plano al cliente (recuerda que no se requiere enviar un ID de credencial en esta llamada). El cliente toma este desafío y comprueba qué passkeys coinciden con el ID de la Relying Party en este autenticador y ofrece la selección a través del menú de autorrelleno, donde el usuario puede seleccionar la passkey apropiada.

Además, también le ahorra al usuario un clic adicional en el botón de inicio de sesión, porque tan pronto como se selecciona la passkey del menú de autorrelleno, comienza el proceso de inicio de sesión.

El CTAP es un protocolo fundamental en el estándar FIDO2, que cierra la brecha de comunicación entre clientes (como navegadores) y autenticadores (como llaves de seguridad, por ejemplo, YubiKeys, o smartphones). Para comprender mejor el CTAP, echemos un primer vistazo breve a las diferentes versiones del protocolo antes de analizar el impacto en las claves residentes y no residentes.

La versión anterior, a menudo denominada Universal 2nd Factor (U2F), fue diseñada principalmente para la autenticación de segundo factor. En U2F, el servidor proporciona un desafío y el autenticador proporciona una respuesta, demostrando la posesión de la clave privada. Sin embargo, U2F no admite claves residentes, lo que significa que siempre requiere una búsqueda del lado del servidor para identificar qué clave usar para un usuario, ya que esto era parte del proceso al solicitar un segundo factor.

El sucesor de U2F, CTAP2, introdujo el soporte para claves residentes, permitiendo la autenticación sin contraseña y sin nombre de usuario. Con las claves residentes, el autenticador almacena el nombre de usuario y el ID de credencial del usuario (junto con el ID de la Relying Party), eliminando la necesidad de que el servidor de la Relying Party lo proporcione durante la autenticación. Este es un salto significativo hacia una experiencia de usuario más fluida.

Sin embargo, CTAP2 viene con desafíos. Un problema notable es la gestión de las claves residentes. Por ejemplo, eliminar una clave residente específica en un dispositivo CTAP2.0 a menudo requiere un restablecimiento completo del dispositivo (lo que también restablece tu clave maestra, lo que significa que todas tus claves no residentes tampoco funcionarán), lo cual no es fácil para el usuario y puede ser problemático en escenarios donde se almacenan múltiples claves residentes en un solo dispositivo. Esto hace que las claves residentes en un dispositivo CTAP2.0 sean un compromiso serio. Realmente no quieres llenar accidentalmente ese espacio limitado que a menudo tienes, especialmente en las llaves de seguridad (por ejemplo, YubiKeys).

CTAP2.1 es una versión posterior de CTAP2, que aporta características y mejoras adicionales al protocolo. Algunos puntos clave sobre CTAP 2.1 incluyen:

• Mejor gestión de claves residentes: CTAP 2.1 permite gestionar, actualizar y eliminar individualmente claves residentes específicas de tu dispositivo.
• Atestación empresarial: Esta característica permite a las empresas tener más control sobre las claves utilizadas por sus empleados. Proporciona una forma para que las empresas verifiquen que las claves que se utilizan son emitidas por la empresa.
• Reconocimiento de múltiples usuarios: Algunos autenticadores pueden reconocer a múltiples usuarios. CTAP 2.1 proporciona una forma para que estos autenticadores indiquen qué usuario ha sido reconocido.
• Compatibilidad con versiones anteriores: CTAP 2.1 está diseñado para ser compatible con CTAP2, asegurando que los dispositivos y plataformas que admiten la versión anterior aún puedan funcionar con la nueva.

Después de haber echado un vistazo a las claves residentes, las claves no residentes y las diferentes versiones de CTAP, ahora analizaremos el lado de la Relying Party y, por lo tanto, el lado del servidor WebAuthn con más profundidad.

La flexibilidad de WebAuthn (pero también su complejidad) se atribuye en gran medida a la configuración de su servidor, particularmente dentro del objeto authenticatorSelection. Este objeto guía al cliente en la selección del autenticador adecuado para la tarea.

{
    "rp": {
        "name": "corbado.com",
        "id": "corbado.com"
    },
    "user": {
        "id": "dGVzdefEyMjE",
        "name": "test-username",
        "displayName": "test-username"
    },
    "challenge": "mhanjsapJjCNaN_Ttasdfk1C0DymR-V_w_0UVOPsdfdfJG2ON_FK5-ODtqp33443tgqHzuuDjv-NUUmMAE4hg",
    "pubKeyCredParams": [
        {
            "type": "public-key",
            "alg": -7
        },
        {
            "type": "public-key",
            "alg": -257
        }
    ],
    "timeout": 60000,
    "excludeCredentials": [],
    "authenticatorSelection": {
        "authenticatorAttachment": "platform",
        "residentKey": "preferred",
        "requireResidentKey": false,
        "userVerification": "preferred"
    },
    "attestation": "none",
    "extensions": {
        "credProps": true
    }
}

Esta opción de servidor especifica cómo está conectado el autenticador al dispositivo cliente. Proporciona información sobre cómo el autenticador se comunica con el cliente:

Valores posibles

• Platform: Indica que el autenticador está conectado a la plataforma del cliente y, por lo tanto, no es extraíble.
• Cross-platform: Indica que el autenticador no está vinculado a la plataforma del cliente y se puede usar en múltiples dispositivos.

Casos de uso y ejemplos

• Platform: Los ejemplos incluyen un escáner de huellas dactilares integrado en un portátil o un sistema de reconocimiento facial en un teléfono, por ejemplo, Face ID, Touch ID o Windows Hello.
• Cross-platform: Los ejemplos incluyen llaves de seguridad USB (por ejemplo, YubiKeys), dispositivos Bluetooth o tarjetas NFC.

En la especificación WebAuthn Nivel 1, esta opción de servidor se llamaba requireResidentKey y podía tener los valores booleanos true (el autenticador debe crear una clave residente) o false (el autenticador debe crear una clave no residente). WebAuthn Nivel 2 reemplazó esta opción de servidor con la nueva opción de servidor residentKey:

Valores posibles

• Required: El autenticador debe crear una clave residente (si no es posible, la operación debe fallar).
• Preferred: El autenticador debería intentar crear una clave residente (si no es posible, debería crear una clave no residente).
• Discouraged: El autenticador debe crear una clave no residente (si no es posible, la operación debe fallar).

Casos de uso y ejemplos

• Required: Ideal para escenarios donde se desea iniciar sesión sin nombre de usuario o donde los usuarios solo deben autenticarse desde dispositivos previamente registrados (agregando una capa extra de seguridad al vincular la credencial del usuario a un dispositivo específico).
• Preferred: Adecuado para escenarios donde el servicio web quiere proporcionar la mejor experiencia de usuario de inicio de sesión posible (a través de claves residentes), pero aún quiere admitir claves no residentes si las claves residentes no son posibles.
• Discouraged: Un servicio quiere ofrecer autenticación con passkeys y también quiere asegurarse de que los usuarios puedan usar cualquier autenticador, incluso aquellos sin capacidades de almacenamiento, sin vincular la credencial a un dispositivo específico.

La verificación del usuario se refiere al proceso que garantiza que la persona que interactúa con el autenticador es el propietario legítimo, generalmente requiriendo un gesto de autenticación específico como introducir un PIN, proporcionar una huella dactilar o usar reconocimiento facial.

A veces, la presencia del usuario (UP) también se menciona o se usa de manera similar a la verificación del usuario, pero tiene algunas diferencias. La presencia del usuario solo confirma que alguien, cualquier persona, está físicamente presente e interactuando con el dispositivo. No verifica la identidad de esa persona. Un simple toque de una llave de seguridad, sin más comprobaciones de identidad, puede ser suficiente para la presencia del usuario. Para las passkeys / WebAuthn, el usuario siempre debe estar presente.

Valores posibles

• Required: La operación debe tener verificación del usuario.
• Preferred: La operación debería tener verificación del usuario si es posible, pero puede proceder sin ella.
• Discouraged: La operación no debería tener verificación del usuario.

Casos de uso y ejemplos

• Required: Ideal para aplicaciones de alta seguridad como la banca o la atención médica, donde verificar la identidad del usuario (por ejemplo, a través de una huella dactilar o un PIN) es crucial.
• Preferred: Útil para aplicaciones generales donde la seguridad adicional es una ventaja pero no estrictamente necesaria.
• Discouraged: Adecuado para operaciones de bajo riesgo o escenarios donde la verificación del usuario podría ser un inconveniente.

Patrón

• Vinculación del autenticador: platform
• Clave residente: required
• Verificación del usuario: required

Ejemplo: Una aplicación corporativa quiere que los empleados inicien sesión sin contraseñas en sus portátiles proporcionados por la empresa utilizando los lectores de huellas dactilares integrados. La credencial se almacena en el dispositivo y el usuario debe verificar con una huella dactilar cada vez.

Patrón

• Vinculación del autenticador: cross-platform
• Clave residente: required
• Verificación del usuario: required

Ejemplo: Un usuario registra una llave de seguridad (por ejemplo, YubiKey) para su banca en línea. Puede usar esta llave para autenticarse en cualquier dispositivo proporcionando la llave de seguridad (por ejemplo, YubiKey), sin necesidad de introducir un nombre de usuario.

Muchas llaves de seguridad basadas en hardware (por ejemplo, YubiKeys) tienen restricciones de almacenamiento inherentes. Esta limitación se debe a la memoria física disponible en el dispositivo y a las consideraciones de diseño del fabricante.

Ejemplo: Una YubiKey podría tener la capacidad de almacenar solo 20 claves residentes. Una vez que se alcanza este límite, no se pueden agregar claves residentes adicionales sin eliminar las existentes.

Solución:

• Uso selectivo de claves residentes: En lugar de usar claves residentes para cada usuario, considéralas para roles o escenarios específicos. Por ejemplo, prioriza las claves residentes para roles de administrador o usuarios con altos privilegios que requieren una seguridad mejorada.
• Educación del usuario: Informa a los usuarios sobre las limitaciones de sus llaves de seguridad (por ejemplo, YubiKeys). Anímales a cambiar a dispositivos que puedan usar claves residentes ilimitadas, como portátiles o smartphones.

Diferentes autenticadores pueden manejar las solicitudes de claves residentes de manera diferente. Algunos pueden crear una clave residente por defecto incluso si no se solicita explícitamente, mientras que otros pueden requerir una instrucción explícita.

El comportamiento inconsistente para diferentes opciones de servidor WebAuthn en diferentes plataformas es un problema importante. Por ejemplo, iOS siempre creará una clave residente independientemente de las opciones de servidor WebAuthn pasadas, mientras que Android requiere una suscripción voluntaria (por ejemplo, con residentKey: preferred o residentKey: required).

Además del comportamiento, es aún peor que, basándose en los datos almacenados del lado del servidor, no se puede decir con un 100 % de certeza si una credencial almacenada es una clave residente o no residente. En cambio, se pueden seguir algunas comprobaciones y acotarlo (ver más abajo), pero aún así hay que esperar que el comportamiento de la credencial sea el que uno cree.

La razón detrás de esto es que hay una sugerencia de WebAuthn para almacenar información sobre el tipo de credencial (clave residente o no residente) en la extensión de propiedades de la credencial (clientExtensionResults.credProps.rk, que es true o false). Sin embargo, proporcionar esta información a la RP no está garantizado, ya que todas las extensiones de WebAuthn son opcionales; por ejemplo, iOS no la envía (por lo que no se sabe si es una clave residente o no residente).

Durante nuestra investigación, intentamos probar el comportamiento en diferentes plataformas y autenticadores (Windows 10, Windows 11, Android 7, Android 13, iOS17, macOS Ventura, YubiKey) con dos páginas de demostración de WebAuthn que proporcionan más detalles sobre las credenciales creadas: https://webauthn.io y https://webauthntest.identitystandards.io/. La última ofrece la posibilidad de trabajar con la propiedad heredada requireResidentKey (WebAuthn Nivel 1) e incluso combinarla con la propiedad residentKey (WebAuthn Nivel 2). Sin embargo, los resultados no fueron fiables (por ejemplo, indicaba clave no residente para iOS pero claramente funcionaba la IU condicional).

El esquema de comprobación más fiable que encontramos es el siguiente:

1. Comprueba cuál es la configuración de tu servidor WebAuthn para el atributo "residentKey".
   1. Si residentKey: required y se crea una credencial con éxito -> es una clave residente.
   2. Si residentKey: preferred o residentKey: discouraged, pasa a la siguiente comprobación.
2. ¿Se admite la extensión credProps.rk y se almacena en la credencial en el servidor?
   1. Si credProps.rk = true, la credencial es una clave residente.
   2. Si credProps.rk = false, la credencial es una clave no residente.
   3. Si credProps está vacío, entonces el tipo de credencial es desconocido.

Como puedes ver, esto ayuda a acotarlo, pero la opción desconocida persiste y no se puede determinar el tipo de clave con un 100 % de certeza.

Esto también está en línea con los hallazgos de William Brown de SUSE en su gran artículo que describe cómo las llaves de seguridad (por ejemplo, YubiKeys) podrían ser inútiles si las Relying Parties requieren claves residentes (hemos ampliado su tabla):

En la tabla, se ve para diferentes opciones de clave residente del servidor WebAuthn si se creó una clave residente (true), si se creó una clave no residente (false) o si sucedió algo más.

Solución:

• Pruebas exhaustivas: Antes de implementar, prueba tu implementación de WebAuthn en una variedad de autenticadores populares para comprender su comportamiento.
• Configuración explícita del servidor: Al configurar tu servidor WebAuthn, sé explícito en tus requisitos. Si solo quieres tener passkeys, entonces establece la opción residentKey en required (nota: esto podría llevar a otros desafíos con autenticadores con capacidad limitada de claves residentes, ver arriba).

Si un usuario alcanza el límite de almacenamiento en su llave de seguridad (por ejemplo, YubiKey), podría enfrentarse a errores o ser incapaz de registrar nuevas credenciales. Esto puede llevar a confusión y frustración.

Solución:

• Manejo de errores elegante: Implementa mensajes de error claros que informen al usuario cuando su llave de seguridad (por ejemplo, YubiKey) está llena y proporciona orientación sobre cómo resolver el problema.
• Flujos de trabajo guiados: Ofrece guías paso a paso o tutoriales sobre cómo los usuarios pueden gestionar sus claves residentes, asegurando que puedan resolver los problemas de forma independiente.

9. Mejores prácticas para desarrolladores y gerentes de producto

Como has visto anteriormente, la configuración del servidor WebAuthn que elijas puede afectar significativamente la experiencia del usuario y la seguridad de tu proceso de autenticación. Es esencial comprender los matices de esta configuración para tomar decisiones informadas.

Claves residentes vs. no residentes: Si la mayoría de tus usuarios acceden principalmente a tu servicio desde dispositivos personales como smartphones o portátiles, las claves residentes son una opción adecuada. Las claves residentes se almacenan en el propio dispositivo y ofrecen una experiencia de autenticación fluida para los usuarios que utilizan con frecuencia el mismo dispositivo. Sin embargo, para los usuarios que utilizan llaves de seguridad (por ejemplo, YubiKeys), que son claves no residentes, podría ser más apropiado.

Configuración de la verificación del usuario (UV): Dependiendo del nivel de seguridad que desees alcanzar, puedes decidir cuán estricto debe ser el proceso de verificación del usuario. Si buscas una alta seguridad, es aconsejable requerir un PIN, huella dactilar o reconocimiento facial (userVerification: preferred o userVerification: required).

Atestación y fiabilidad: La atestación te permite verificar el origen y la integridad del autenticador. Decide si quieres confiar en todos los autenticadores o solo en los de fabricantes específicos. Esto puede ser crucial si manejas datos sensibles y quieres asegurarte de que solo se utilicen autenticadores de alta calidad y confianza.

Mecanismos de respaldo: Siempre ten un mecanismo de respaldo. Si un usuario pierde su autenticador o si este funciona mal, debería tener una forma alternativa de acceder a su cuenta. Esto podría ser a través de códigos de respaldo, verificación por SMS, enlaces mágicos por correo electrónico u otros métodos de autenticación multifactor.

Educación continua: El panorama de las passkeys y WebAuthn está en constante evolución. Mantente actualizado con los últimos desarrollos, vulnerabilidades y parches. Anima a tu equipo de desarrollo a participar en talleres, seminarios web y conferencias relacionadas con las passkeys y WebAuthn.

Incorporación y educación del usuario: Al introducir la autenticación con passkeys, asegúrate de que tus usuarios entiendan sus beneficios y cómo funciona. Ofrece instrucciones claras durante el proceso de registro y proporciona recursos (como preguntas frecuentes o tutoriales en video) para ayudar a los usuarios a configurar y usar las passkeys.

Al adherirse a estas mejores prácticas, los desarrolladores y los gerentes de producto pueden asegurarse de que implementan la autenticación con passkeys de manera efectiva, equilibrando tanto la seguridad como la experiencia del usuario.

Si quieres implementar passkeys para una adopción generalizada en tu sitio web o aplicación y no necesitas admitir llaves de seguridad (por ejemplo, YubiKeys), ya que la mayoría de tus usuarios simplemente usarán su smartphone o portátil, recomendamos la siguiente configuración.

• authenticator: platform
• residentKey: required
• userVerification: required

Beneficios:

• Como todas las claves creadas son claves residentes, la configuración permite la IU condicional, haciendo que tu inicio de sesión sea aún más fluido para tus usuarios, ya que no tienen que recordar un nombre de usuario.
• Todos los dispositivos modernos de Apple, Google y Microsoft son compatibles y usan passkeys.

La configuración del servidor de WebAuthn, aunque compleja, ofrece un marco robusto y flexible para la autenticación. Dominar esta configuración es crucial, ya que no se trata solo de implementar un nuevo estándar; se trata de mejorar fundamentalmente la seguridad y la eficiencia de la autenticación de usuarios.

En esencia, comprender la configuración del servidor de WebAuthn es una inversión en la construcción de aplicaciones más seguras, eficientes y con visión de futuro. A medida que evoluciona el panorama digital, estar bien versado en tales tecnologías será indispensable. Para mantenerte actualizado, únete a nuestra comunidad de passkeys o suscríbete a nuestro boletín a continuación.