¿Las passkeys identifican a los usuarios? Riesgos de WebAuthn

Las passkeys usan WebAuthn para crear y utilizar credenciales de clave pública. Un navegador también puede exponer información limitada sobre la disponibilidad de algunos flujos de WebAuthn. Esos resultados pueden ayudar a una parte confiable a decidir qué opción de inicio de sesión mostrar. Son indicios de funciones, no un inventario de hardware, una prueba de identidad, una prueba de que existe una credencial ni una garantía de que un inicio de sesión posterior tendrá éxito. BotBrowser puede mantener los resultados de capacidad de WebAuthn coherentes con un perfil en un contexto controlado; no puede convertir esos resultados en una prueba de un dispositivo o de una credencial.

Esta distinción importa para la privacidad y el diseño del producto. El resultado de una capacidad puede variar según el soporte del navegador, la política del sistema operativo, el estado de la cuenta, los autenticadores disponibles y el contexto actual. Tratarlo como una afirmación definitiva sobre un dispositivo convierte una entrada de compatibilidad en una inferencia sin fundamento. Tratarlo como un resultado de credencial puede producir una experiencia de inicio de sesión confusa.

La especificación WebAuthn Level 3 define las interfaces del navegador y las ceremonias de credenciales pertinentes. La referencia de PublicKeyCredential de MDN ofrece la documentación orientada al navegador. Juntas respaldan un modelo cuidadoso: la disponibilidad de una capacidad, la verificación del usuario, el uso del autenticador, la creación de credenciales y su recuperación son eventos relacionados, pero distintos.

Resumen

• isUserVerifyingPlatformAuthenticatorAvailable() devuelve un booleano sobre si ahora se puede descubrir un autenticador de plataforma con verificación de usuario, y no nombra autenticador, sensor, cuenta ni credencial.
• isConditionalMediationAvailable() solo indica si la mediación condicional está disponible, no el resultado de un inicio de sesión, así que un método ausente o un valor false sigue exigiendo otra ruta visible.
• El contexto seguro, el origen y el RP ID delimitan cada ceremonia: navigator.credentials.create() y navigator.credentials.get() solo producen algo verificable por el servidor para el RP ID que firmó el desafío.
• Un aviso cancelado, un desafío caducado, un RP que no coincide y un autenticador no disponible son cuatro desenlaces distintos, y ninguno pertenece a un atributo permanente de la cuenta.
• BotBrowser puede repetir una configuración documentada de capacidades del cliente para comprobar que la página de inicio conserva su alternativa, pero no crea hardware de autenticador, no inscribe credenciales ni verifica una aserción.

Contenido

• Ver el video
• Mapa de fuentes y afirmaciones
• Qué puede significar un resultado de capacidad
• Límites de origen y de la parte confiable
• Límites de privacidad de los indicios de WebAuthn
• Diseño de un flujo de inicio de sesión respetuoso
• Conclusión práctica

Ver el video

Este video en inglés comprueba qué respuestas puede leer una página con las llamadas de capacidad de WebAuthn, primero en una página de laboratorio local con tres conjuntos de capacidades declarados y después en dos compilaciones reales de Chrome en Windows y Ubuntu. No se crea ninguna credencial y la comprobación no establece identidad, anonimato, acceso ni la decisión de un sitio remoto. El audio está en inglés.

Mapa de fuentes y afirmaciones

• Contexto seguro y PublicKeyCredential (referencia normativa/de API): la referencia de PublicKeyCredential de MDN documenta el requisito de contexto seguro. Recomendación del artículo: tratarlo como requisito de compatibilidad, nunca como prueba de que exista un autenticador o una credencial.
• Disponibilidad del autenticador de plataforma (referencia normativa/de API): W3C 5.1.6 y la referencia del método en MDN definen una comprobación de disponibilidad, no la existencia de una credencial. Recomendación del artículo: usar el booleano solo para decidir si se ofrece una ruta con autenticador de plataforma.
• Mediación condicional (referencia normativa/de API): las capacidades del cliente en W3C y la referencia de mediación condicional de MDN describen un indicador de disponibilidad, no un resultado de inicio de sesión. Recomendación del artículo: conservar otra ruta cuando falte el método o no esté disponible.
• Origen, RP ID y ceremonia (reglas normativas del protocolo): las reglas de origen y RP ID de W3C limitan las credenciales a la parte confiable, y los algoritmos de ceremonia requieren solicitud, participación del usuario y respuesta verificada. Recomendación del artículo: decidir sobre cuenta, autorización y recuperación solo tras verificar la respuesta en el servidor; no inferirlo de una señal de capacidad.

Qué puede significar un resultado de capacidad

La interfaz PublicKeyCredential solo está disponible en contextos seguros. Por tanto, el transporte seguro es un requisito previo para usar WebAuthn, pero no demuestra que haya un autenticador o una credencial disponibles. Una página puede no tener acceso a WebAuthn porque el contexto no es seguro, porque el navegador no admite la interfaz correspondiente o porque falta un método opcional concreto. Cada caso requiere una experiencia distinta.

La sección 5.1.6 de WebAuthn Level 3 define isUserVerifyingPlatformAuthenticatorAvailable(). La especificación indica que las partes confiables lo usan para determinar si pueden crear una credencial nueva con un autenticador de plataforma que verifique al usuario. El resultado es un booleano derivado de un procedimiento de la plataforma cliente que descubre los autenticadores de plataforma disponibles con verificación de usuario. Un resultado verdadero sirve para decidir si se ofrece una ruta de registro con ese autenticador. No nombra el autenticador, revela un sensor concreto, demuestra la inscripción de un usuario ni confirma que el sitio ya tenga registrada una credencial.

La palabra plataforma es importante. En WebAuthn, la vinculación de un autenticador y su capacidad de verificar al usuario son conceptos del protocolo. No autorizan a un sitio a convertir una respuesta booleana en una afirmación sobre la biometría o el hardware de una persona. Un dispositivo puede ofrecer varios autenticadores y el usuario puede elegir otro durante una ceremonia. Los ajustes, las políticas empresariales, la configuración de la cuenta o los cambios en un autenticador pueden afectar a lo que se puede usar cuando comienza la ceremonia.

La sección 5.1.7 de la especificación Level 3 describe las capacidades del cliente como un conjunto limitado de claves para ofrecer ciertos flujos y experiencias. Ese propósito es más limitado que la identidad o la clasificación del dispositivo. Por ejemplo, un resultado puede indicar si la pantalla de inicio de sesión ofrece una ruta junto al campo de nombre de usuario. No debe usarse para etiquetar a un visitante, inferir la presencia de una credencial ni decidir que la recuperación de contraseña es innecesaria.

La mediación condicional exige el mismo cuidado. La especificación describe isConditionalMediationAvailable() como un indicador de disponibilidad para la mediación condicional. Puede ayudar a una aplicación a elegir una interfaz, pero no realiza un inicio de sesión ni demuestra que haya una passkey disponible para la parte confiable actual. MDN lo enumera como método estático de PublicKeyCredential y señala que la API se limita a contextos seguros en los navegadores compatibles. La aplicación debe tratar un método ausente o un resultado no disponible manteniendo otra ruta de inicio de sesión.

Disponibilidad, verificación del usuario y credenciales

La disponibilidad es la primera capa. Pregunta si el navegador puede exponer una opción concreta de WebAuthn en el entorno actual. No afirma que el usuario pueda autenticarse. La verificación del usuario es otra capa: es una propiedad solicitada y evaluada durante una ceremonia de credenciales, en la que el autenticador puede tener que verificar al usuario según la solicitud y su propia política. Un resultado de capacidad no completa esa verificación.

La disponibilidad del autenticador también es independiente de la disponibilidad de credenciales. Un autenticador de plataforma puede estar disponible aunque no se haya creado ninguna credencial para un sitio. A la inversa, un usuario puede tener una credencial válida utilizable mediante un autenticador distinto del que esperaba la aplicación. La forma fiable de saber si el inicio de sesión puede completarse es ejecutar la solicitud WebAuthn normal después de que el usuario elija esa ruta y de que la aplicación proporcione los datos correctos de la parte confiable.

La creación de credenciales y las aserciones son operaciones activas. Durante el registro, el navegador y el autenticador pueden crear una credencial de clave pública nueva después de que la parte confiable la solicite. Durante la autenticación, pueden producir una aserción para una credencial existente. Estas operaciones pueden tener éxito, ser rechazadas o canceladas por el usuario, no estar disponibles o fallar por otros motivos específicos de la solicitud. Una comprobación de capacidad no puede sustituir ninguna de las dos.

La descripción de la interfaz PublicKeyCredential en la especificación Level 3 hace visible esta separación. Una credencial devuelta tiene una respuesta después de crear una credencial nueva o solicitar una aserción. En cambio, un método de capacidad devuelve información para orientar un posible flujo. Las aplicaciones deben modelarlos como estados separados en la interfaz y la telemetría. «Puede ofrecerse esta opción» no equivale a «el usuario la aprobó», «se creó una credencial» o «se verificó una aserción».

La cancelación merece un tratamiento explícito. Una persona puede cerrar o rechazar el aviso del autenticador. Ese resultado no prueba su identidad, su hardware ni su disposición a usar passkeys en todos los contextos: es un resultado de interacción. Ofrece un camino claro de vuelta a la contraseña, la recuperación u otro método compatible, y no repitas una ceremonia sin una acción nueva del usuario. Una interfaz considerada explica la elección antes de abrir el flujo de autenticación y ofrece una salida clara después.

El mismo principio se aplica a los errores. Un autenticador no disponible, un desafío de servidor caducado, una discordancia de RP, una cuenta modificada y una política del navegador pueden producir resultados distintos. Los equipos de producto solo deben registrar el detalle diagnóstico necesario para ayudar al usuario y evitar convertir una categoría de fallo en un perfil persistente. La introducción a la identificación mediante permisos del navegador aporta contexto relacionado para tratar los estados expuestos por el navegador como señales limitadas y no como hechos de identidad.

Límites de origen y de la parte confiable

WebAuthn tiene un alcance deliberadamente limitado. La especificación Level 3 indica que las operaciones se circunscriben a un origen concreto y que el origen completo del solicitante se incluye y firma en los objetos de atestación y las aserciones. También indica que cada credencial se circunscribe a un identificador de parte confiable, o RP ID. Un autenticador restringe las credenciales creadas para un RP ID a las operaciones solicitadas por ese mismo RP ID.

Estos límites explican por qué un resultado de capacidad no puede demostrar acceso a credenciales entre sitios. Un sitio recibe una aserción solo mediante una ceremonia para su propio origen y RP ID, sujeta a la validación del navegador y al procesamiento del autenticador. No puede usar un indicio general de capacidad como sustituto de las comprobaciones de origen y de parte confiable del protocolo. El requisito de contexto seguro forma parte del mismo modelo de seguridad.

Para una aplicación, la regla práctica es sencilla. Inicia una ceremonia de registro o de inicio de sesión solo para el origen y RP ID previstos del sitio. Deja que el navegador y el autenticador hagan cumplir sus funciones. Verifica la respuesta del servidor según el protocolo WebAuthn antes de considerar completo el inicio de sesión. No bases las decisiones de descubrimiento de cuentas, autorización o recuperación en una respuesta de capacidad del cliente.

Los orígenes relacionados necesitan una configuración deliberada, no suposiciones. La especificación incluye reglas para usar WebAuthn entre orígenes relacionados. Compartir el nombre de una organización o tener un nombre de host parecido no crea por sí solo una relación de credenciales. Los equipos que operan varios sitios deben definir su RP ID y su política de origen antes de lanzar un flujo de passkeys, probarlo en sus dominios compatibles y documentar el comportamiento alternativo cuando esa relación no se aplica.

El límite de origen también mejora la privacidad. Limita la capacidad de una parte confiable para usar credenciales WebAuthn emitidas para otra parte confiable. Esa protección no significa que las decisiones de recopilación del sitio sean automáticamente respetuosas con la privacidad. El sitio debe minimizar lo que registra, explicar por qué ofrece una opción de autenticación y evitar usar información de compatibilidad para perfiles ajenos.

Límites de privacidad de los indicios de WebAuthn

La información de capacidad puede contribuir a un conjunto más amplio de datos expuestos por el navegador. Un resultado puede ser útil junto con otra información para decisiones de compatibilidad y puede cambiar cuando cambian el software, la política o el estado de la cuenta. Por eso no es un identificador estable ni una descripción fiable de un dispositivo físico. No puede demostrar que un visitante posee un dispositivo concreto, dispone de un método biométrico específico o tiene una cuenta en una parte confiable.

Esta limitación es especialmente importante cuando una aplicación decide qué conservar. Un booleano o un registro pequeño de capacidades puede bastar para elegir entre las opciones de inicio de sesión visibles durante la visita actual. No tiene que convertirse en un atributo de cuenta, una dimensión analítica ni un identificador duradero. Conservarlo para esos fines ajenos aumenta la posibilidad de que más adelante se malinterprete una condición de compatibilidad pasajera. Si el registro diagnóstico es necesario, define un periodo breve de conservación, restringe el acceso y documenta el motivo operativo de recopilarlo.

Los sitios también deben distinguir la información que el usuario proporciona intencionadamente de la que se infiere del soporte del navegador. Un identificador de cuenta introducido en un formulario, la selección explícita de un método de inicio de sesión y una ceremonia de credenciales completada tienen significados y expectativas de privacidad distintos. Un indicio de función no pertenece a ninguna de esas categorías. Mostrar una opción de passkey no es consentimiento para iniciar una ceremonia, y rechazar un aviso no es consentimiento para guardar una preferencia sobre la persona.

La accesibilidad y la recuperación dependen de la misma distinción. Algunas personas usan autenticadores externos, dispositivos compartidos, tecnología de asistencia o rutas de recuperación que no se parecen a un flujo típico de autenticador de plataforma. Un resultado de capacidad no debe eliminar las rutas que necesitan. Mantén las etiquetas centradas en la acción ofrecida, evita suposiciones sobre el dispositivo del usuario y permite salir del flujo sin perder el progreso. Estas decisiones hacen más útil la pantalla de inicio de sesión incluso cuando WebAuthn es compatible.

Los equipos de soporte también se benefician de un lenguaje preciso. Un informe puede decir que se ofreció una opción de passkey, que una persona la canceló o que el servidor no verificó una aserción. No debe decir que alguien carece de hardware biométrico ni que un navegador es definitivamente un entorno concreto basándose en un solo resultado. Las descripciones acotadas conservan un contexto útil para resolver problemas sin convertir un estado del protocolo en una afirmación de identidad.

La navegación privada también requiere un lenguaje matizado. Los navegadores pueden aplicar comportamientos distintos de almacenamiento, cuentas, permisos y credenciales en contextos privados. La especificación WebAuthn no dice que toda ventana privada deba devolver los mismos valores de capacidad ni completar las mismas ceremonias que una ventana normal. Las aplicaciones deben probar los navegadores y modos que admiten y conservar una alternativa cuando WebAuthn no esté disponible. No se debe decir a los usuarios que la navegación privada hace que una respuesta WebAuthn sea idéntica, anónima o predecible.

El modo de visualización tampoco permite una conclusión universal. Un entorno con interfaz o sin ella puede variar según la compilación del navegador, el sistema operativo, la política, los autenticadores disponibles y la configuración de prueba. El estándar define la semántica de WebAuthn, no una igualdad garantizada entre modos de visualización. Los equipos que necesiten compatibilidad entre entornos deben probar su propia matriz admitida y comunicar el soporte observado de forma acotada. No deben usar un único resultado para caracterizar todos los navegadores sin interfaz o de escritorio.

Eliminar una interfaz, sustituir un método del navegador o intentar forzar un resultado no es un control de privacidad fiable. Puede volver inexacta la decisión de compatibilidad de una aplicación o interrumpir un flujo de autenticación. Más importante aún, un flujo de cuenta público no debe prometer que una configuración será invisible para un sitio o inmune a inferencias adicionales. Las afirmaciones de privacidad deben limitarse a lo que el usuario puede observar y a lo que la documentación del producto puede respaldar.

Para los usuarios, las preguntas útiles son concretas: ¿explica el sitio qué hace la opción de passkey? ¿Puede el usuario elegir otro método de inicio de sesión? ¿Solicita el sitio una credencial solo después de que el usuario elija esa ruta? ¿Conserva el sitio únicamente la información que necesita para operar la cuenta de forma segura? Estas preguntas son más prácticas que intentar deducir identidad o certeza sobre el hardware a partir de un indicio de función.

La guía sobre propiedades de navigator e identificación desarrolla el principio general. Los valores individuales del navegador pueden servir como entradas de compatibilidad, pero su significado depende del contexto. Las decisiones de privacidad deben centrarse en minimizar datos, ofrecer elecciones comprensibles y probar el comportamiento compatible, no en tratar una respuesta de API como un perfil concluyente.

Diseño de un flujo de inicio de sesión respetuoso

Ofrece las passkeys como una opción explícita de inicio de sesión o registro. Un indicio de capacidad puede ayudar a decidir si se muestra una opción de forma destacada, pero el usuario debe decidir si continúa. Mantén visible una contraseña, una recuperación u otra ruta compatible cuando falte la capacidad, no se admita la función opcional, la persona decline o una operación no se complete. La alternativa forma parte de la experiencia de inicio de sesión, no es un añadido excepcional.

Usa textos de interfaz concisos y específicos. Di que se puede crear o usar una passkey para la cuenta actual. No digas que ya hay una credencial disponible hasta que una ceremonia de autenticación produzca un resultado verificado por el servidor. No insinúes que el usuario debe tener un tipo concreto de hardware. Puede usar un autenticador externo compatible, otro dispositivo u otro método de inicio de sesión.

Mantén separadas las comprobaciones de compatibilidad y las ceremonias de credenciales en la lógica del producto. La primera puede influir en la presentación. La segunda requiere una solicitud de la parte confiable, el procesamiento del navegador y el autenticador, y la participación del usuario. Tras una cancelación o un fallo, devuelve a la persona a una elección comprensible en lugar de inferir una preferencia permanente. Los límites de frecuencia, controles contra el fraude y políticas de seguridad de cuentas deben usar sus propias entradas documentadas, no reutilizar la disponibilidad de WebAuthn como puntuación de riesgo.

Al probar un flujo, cubre resultados en lugar de intentar deducir un perfil del dispositivo. Incluye un navegador donde la capacidad opcional no esté disponible, un usuario que elija otro método, una cancelación, un registro completado y un inicio de sesión cuya aserción verifique el servidor. Prueba las combinaciones de origen y RP ID admitidas. Repite estas comprobaciones después de actualizar el navegador o el sistema operativo, porque el soporte opcional y el tratamiento de errores pueden cambiar.

Documenta el límite del servicio. El autenticador del navegador y la parte confiable tienen responsabilidades separadas. La parte confiable crea la solicitud y verifica la respuesta en su servidor. El navegador coordina la interacción. El autenticador cumple su función en el protocolo. Una respuesta de capacidad no transfiere credenciales a un sitio, y el sitio no debe describirla como consentimiento para crear, recuperar o compartir una credencial. Cualquier cambio de cuenta o transferencia de datos fuera del límite esperado necesita una elección clara del usuario.

BotBrowser documenta capacidades de cliente WebAuthn controladas por perfil. Si realizas pruebas autorizadas de privacidad o compatibilidad, esto te permite repetir una configuración documentada del navegador y comprobar que tu página de inicio de sesión sigue ofreciendo una alternativa cuando las opciones de passkey difieren. No puede demostrar ni crear hardware físico de autenticación, inscripción de credenciales ni un inicio de sesión verificado, y no controla las reglas de origen y RP ID de tu parte confiable, la verificación en el servidor ni su política de retención. Valida tu configuración admitida frente a las definiciones públicas de WebAuthn y a tu propio flujo de cuenta. La guía de gestión de perfiles ofrece orientación general para gestionar perfiles sin convertir un ajuste del perfil en una afirmación de identidad.

Fuentes

• W3C Web Authentication: WebAuthn Level 3: la sección 5.1.6 define el método de disponibilidad del autenticador de plataforma con verificación de usuario; la sección 5.1.7 define las capacidades del cliente; la sección 5.1 y el modelo de seguridad describen contextos seguros, orígenes, respuestas y el alcance del RP ID.
• MDN: Web Authentication API: visión general, orientada al navegador, del registro, la autenticación y las passkeys.
• MDN: PublicKeyCredential: aviso sobre contextos seguros y métodos estáticos de PublicKeyCredential, incluida la mediación condicional y la disponibilidad del autenticador de plataforma con verificación de usuario.

Conclusión práctica

Decide qué puede cambiar cada respuesta antes de conectarla a una pantalla. Un true de isUserVerifyingPlatformAuthenticatorAvailable() permite destacar el botón de passkey, un true de isConditionalMediationAvailable() permite activar la ruta condicional de navigator.credentials.get(), y ambos dejan intactas la contraseña y las vías de recuperación. Ninguno de los dos justifica ocultar una ruta, escribir una marca en la cuenta o concluir que la recuperación ya no hace falta.

Después prueba desenlaces y no dispositivos. Cubre un navegador donde falta el método opcional, una persona que elige la contraseña, una ceremonia cancelada, un registro que se completa y un inicio de sesión que el servidor verifica contra el desafío firmado y tu RP ID. Guarda en el registro solo la rama y el desenlace, y deja que los campos de diagnóstico caduquen con el caso.

Si la entrega incluye una configuración de capacidades del cliente controlada por perfil, repite la misma página sobre ella y confirma que la alternativa sigue apareciendo cuando el soporte de passkeys difiere. Anota la compilación del navegador, la revisión del perfil, el origen y el RP ID junto a ese resultado, y descríbelo como una configuración admitida y no como una afirmación sobre cualquier autenticador que traiga el visitante.