Por qué las passkeys son seguras — Mecanismo, sincronización y qué vigilar si se pierde un dispositivo

«Se puede iniciar sesión con la huella, así que es seguro.» Las passkeys se presentan a veces así, pero el centro de su seguridad no es la huella ni el rostro. Está en demostrar con una firma que se posee la clave de ese sitio, sin entregar la clave privada al servicio en el que se inicia sesión.¹

Dicho esto, si se entiende como «con una passkey es imposible que te usurpen la cuenta» o «la clave privada no sale nunca del teléfono», se toman mal las decisiones sobre la sincronización y sobre un dispositivo perdido. Que el mecanismo de inicio de sesión se fortalezca es una cosa; que el dispositivo, los medios de recuperación y la sesión posterior al inicio de sesión se vuelvan seguros automáticamente es otra.

Este artículo parte de la diferencia con las contraseñas, ilustra el flujo de registro e inicio de sesión y, a continuación, ordena por qué resisten el phishing, en qué se diferencian las sincronizadas y las vinculadas al dispositivo, y qué hacer cuando se pierde un dispositivo. La segunda mitad cubre los puntos a comprobar al introducirlas en un servicio web propio o en sistemas de negocio de Windows.

En el diagrama, una línea continua marca una relación que siempre se cumple y una línea discontinua una relación condicional (las condiciones están en la explicación de cada relación en la página de detalle). La lista completa de relaciones (38 en total, con evidencia y grado de certeza) y las definiciones de los conceptos principales están reunidas en la página de detalle del mapa de conocimiento (en japonés). Datos: JSON-LD / Turtle

1. Hay tres razones por las que las passkeys son seguras

Una passkey es una credencial basada en criptografía de clave pública que se puede usar para iniciar sesión en lugar de una contraseña. Del par de claves creado al registrarse, la clave privada la gestiona el usuario y la pública se registra en el servicio. En la web, el registro y la autenticación usan la API estándar WebAuthn.¹²

flowchart TB
        accTitle: Tres debilidades de la autenticación que cambia la passkey
        accDescr: La entrega del secreto, la reutilización de respuestas y el error de destino se abordan cada uno con un mecanismo distinto.
        A["Inicio de sesión con passkey"] --> B["Devolver una firma sin entregar la clave privada"]
        A --> C["Cotejar el desafío y consumirlo"]
        A --> D["Comprobar el RP ID y el origen"]
        B --> E["Con la clave pública sola no se puede falsificar la firma"]
        C --> F["No dejar reutilizar respuestas anteriores"]
        D --> G["No dejar usarla en un sitio falso no relacionado"]

Figura 1: La fortaleza de la passkey está en combinar criptografía, una petición de un solo uso y la restricción del destino de uso.

El destino de «no enviar la clave privada» en este artículo es el servidor del servicio en el que se inicia sesión. En las passkeys sincronizadas hay otro camino que cifra, guarda y replica la clave privada. Separar ambos resuelve la duda de «si se sincroniza en la nube, ¿cómo es que no se envía el secreto?».

Además, el servidor guarda, además de la clave pública, el identificador de la credencial, la correspondencia con la cuenta, información de sesión, etc. «Con la clave pública sola no se puede suplantar» y «no hace falta proteger la base de datos» no significan lo mismo.²

2. Qué queda con las contraseñas largas y los códigos de un solo uso

En la autenticación habitual por contraseña, el usuario envía la contraseña introducida al servidor por una comunicación protegida con TLS, y el servidor la coteja con un hash u otro valor guardado. Un hash con sal adecuado y un coste de cálculo suficiente dificultan los ataques que, tras un filtrado, prueban combinaciones una y otra vez. Las contraseñas aleatorias, largas y no reutilizadas también tienen sentido.³

Si se reutiliza la misma contraseña en varios servicios, un «ataque de relleno de credenciales» (password spraying / credential stuffing) que prueba en otros sitios el par de identificador y contraseña filtrado en uno puede extender el daño a otras cuentas. Aunque la contraseña sea larga, si se reutiliza no se evita esa propagación.⁴

Aun así, sigue siendo posible entregar la contraseña correcta al interlocutor equivocado. Si se introduce la contraseña genuina en un sitio preparado por el atacante, aunque el certificado TLS de ese sitio sea correcto, el valor introducido llega al atacante. No es que se haya roto TLS: se ha confundido con quién se está comunicando de forma segura.

sequenceDiagram
        accTitle: TLS solo no impide introducir datos en un sitio falso
        accDescr: La contraseña y el código que el usuario introduce en un sitio falso llegan a quien lo opera, aunque la comunicación esté cifrada.
        participant U as Usuario
        participant P as Sitio falso
        participant S as Servicio genuino
        U->>P: Introduce la contraseña genuina
        P->>S: Retransmite la contraseña introducida
        S-->>P: Pide autenticación adicional
        P-->>U: Pide un código de un solo uso
        U->>P: Introduce el código
        P->>S: Retransmite el código mientras sigue siendo válido
        S-->>P: Si la verificación tiene éxito, emite una sesión

Figura 2: Esquema del phishing de tipo AiTM, que retransmite en tiempo real la contraseña y el código.

TOTP es un método en el que la aplicación de autenticación y el servidor comparten una semilla y generan un código según la hora. No se envía la semilla en sí en cada inicio de sesión. Sin embargo, el código que introduce el usuario no está ligado al dominio del sitio legítimo, así que cabe retransmitirlo desde un sitio falso mientras sigue vigente. Los códigos por SMS tienen el mismo problema de poder introducirse en un sitio falso.³

Esto no significa que la autenticación multifactor no sirva. Se evitan más ataques que con solo contraseña. Aun así, frente a los ataques que apuntan también a la introducción manual del código, tiene sentido avanzar hacia una autenticación resistente al phishing como FIDO/WebAuthn.⁵

También es eficaz generar contraseñas fuertes con un administrador de contraseñas y autocompletarlas solo en el dominio correcto. Sin embargo, esa contraseña se puede copiar y pegar en otro campo. La passkey se diferencia en que el usuario no puede, solo con su operación, quitar esa restricción de destino.

3. Qué circula en el registro y en el inicio de sesión

En el registro se crea un par de claves y se vincula a la cuenta

Hay tres papeles principales en el trato de las passkeys. El RP (Relying Party) del lado del servicio, el navegador o el sistema operativo que ofrece WebAuthn, y el autenticador que genera y usa las claves. Entre los autenticadores hay los que se coordinan con funciones del sistema operativo o con un administrador de credenciales, y las claves de seguridad FIDO2 externas. La comprobación de rostro o huella es el proceso que autoriza ese uso.²⁶

sequenceDiagram
        accTitle: Flujo de registro de una passkey
        accDescr: Ante una petición de registro se crea un par de claves, y el servicio verifica la respuesta de registro y vincula la clave pública y el identificador de credencial a la cuenta.
        participant S as Servicio
        participant B as Navegador y sistema operativo
        participant A as Autenticador
        S->>B: Desafío e información de la cuenta
        B->>B: Comprobar el destino de uso
        B->>A: Petición de creación de credencial
        A->>A: Comprobación de identidad y generación del par de claves
        A-->>B: Clave pública, identificador de credencial, etc.
        B->>S: Enviar la respuesta de registro
        S->>S: Verificar la respuesta de registro
        S->>S: Registrar la credencial en la cuenta

Figura 3: Lo que se registra no es solo la clave pública: es una respuesta que incluye identificadores y datos de verificación. La clave privada no se envía al destino del inicio de sesión.

El credential ID (identificador de credencial) es el valor que identifica qué passkey es. El servidor lo guarda asociado a la clave pública y a la cuenta. Al añadir una passkey nueva a una cuenta existente, primero se confirma con un método ya existente que se trata de ese usuario y, si hace falta, se vuelve a autenticar. No se debe decidir el destino del registro solo con el nombre de usuario enviado por el navegador.⁶⁷

Por lo general, al registrarse en otro servicio o en otra cuenta se crea otro par de claves, así que el usuario no tiene que hacer el equivalente a reutilizar contraseñas. Sin embargo, no es un mecanismo que impida también cotejar al usuario por otra información, como una dirección de correo: no significa que «con passkeys se es anónimo».

En el inicio de sesión se devuelve una firma de la petición actual

Al iniciar sesión, el servidor emite un desafío, un número aleatorio difícil de predecir. El autenticador firma con la clave privada y el navegador lo devuelve al servidor. El servidor verifica con la clave pública registrada y comprueba que es una respuesta correcta a la petición emitida esta vez.⁶

sequenceDiagram
        accTitle: Flujo de inicio de sesión con passkey
        accDescr: El autenticador crea una firma ligada a la petición actual, y el servidor verifica la firma, el desafío, el destino de uso y la cuenta.
        participant S as Servicio
        participant B as Navegador y sistema operativo
        participant A as Autenticador
        S->>B: Desafío no usado y RP ID
        B->>B: Comprobar la validez del destino de uso
        B->>A: RP ID y hash de los datos
        A->>A: Confirmar con biometría o PIN
        A->>A: Firmar con la clave privada
        A-->>B: Datos del autenticador y firma
        B->>S: Identificador de credencial y respuesta de autenticación
        S->>S: Verificar la respuesta y la cuenta
        S-->>B: Emitir sesión solo si tiene éxito

Figura 4: La respuesta del inicio de sesión es «la prueba de que se posee la clave privada», no la clave privada en sí.

Con más precisión, los datos firmados en la autenticación son los siguientes. || representa la concatenación de secuencias de bytes.⁸

firma = authenticatorData || SHA-256(clientDataJSON)

clientDataJSON:
  type       en autenticación, webauthn.get
  challenge  el desafío emitido por el servidor
  origin     el origen del llamador

authenticatorData:
  rpIdHash   hash SHA-256 del RP ID
  flags      resultado de presencia del usuario, verificación de usuario, etc.
  signCount  contador de firmas

«Firmar el desafío» es una explicación abreviada para captar el conjunto. En la práctica, el destino de uso y el estado del autenticador también intervienen en la verificación de la firma. También importa la división de papeles: el autenticador no lee la página web para decidir el origen; recibe el hash de los datos de cliente que ha reunido el navegador.

flowchart TB
        accTitle: Datos que se ligan a la firma en la autenticación
        accDescr: Se concatenan el hash de los datos de cliente, que incluyen el desafío y el origen, con los datos del autenticador, que incluyen el hash del RP ID, y se firma el resultado.
        A["Desafío, origen, etc."] --> B["Hash de clientDataJSON"]
        C["Hash del RP ID, flags, etc."] --> D["authenticatorData"]
        B --> E["Concatenar datos del autenticador y hash"]
        D --> E
        E --> F["Firmar con la clave privada"]

Figura 5: No solo el desafío: el destino de uso y el estado del autenticador también intervienen en la verificación de la firma.

Que no se puedan reutilizar firmas anteriores no se debe a que la firma caduque con el tiempo. Se debe a que el servidor liga el desafío al intento de inicio de sesión, le pone un plazo y no vuelve a aceptar una petición ya usada. Que la verificación de la firma con la clave pública tenga éxito no basta, por sí solo, como condición para permitir el inicio de sesión.

4. Por qué no se puede usar ni en un sitio falso idéntico al genuino

El RP ID y el origen tienen papeles distintos

El RP ID es el nombre de dominio que delimita el alcance de la credencial; suele especificarse como example.com. El origen, en cambio, es el conjunto de esquema, host y puerto. Por ejemplo, https://login.example.com como origen y example.com como RP ID.⁹

En la verificación por la relación habitual de dominios, una página de login.example.com puede especificar example.com como RP ID. Sin embargo, una página de un examp1e.com no relacionado no puede especificar example.com y usar la passkey del sitio genuino. No se trata de si el aspecto se parece: el navegador verifica la relación del destino de uso.

flowchart TB
        accTitle: Restricción del destino de uso de la credencial por el RP ID
        accDescr: En una página con la relación de dominio legítima y en un sitio falso no relacionado, la decisión del navegador al pedir el RP ID genuino es distinta.
        A["Se especifica example.com como RP ID"] --> B{"¿De dónde viene la llamada?"}
        B -->|"login.example.com"| C["Cumple las condiciones de relación de dominio"]
        B -->|"examp1e.com"| D["Dominio no relacionado: se rechaza"]
        C --> E["Seguir la autenticación con la passkey correspondiente"]
        E --> F["El servidor también verifica si el origen está permitido"]
        D --> G["No se puede usar la passkey del sitio genuino"]

Figura 6: Tanto la restricción de destino del navegador como la verificación de origen del servidor sostienen la resistencia al phishing.

También del lado del servidor se verifica que el origin devuelto con la firma sea un origen ya permitido y que el rpIdHash sea el hash del RP ID esperado. No se debe aceptar, como autenticación de la cuenta genuina, una clave creada con el RP ID del propio sitio falso ni una respuesta de un origen no permitido.⁸

WebAuthn Level 3 incluye, además, Related Origin Requests, para usar el mismo RP ID en otro origen que el servicio haya asociado de forma explícita. Tampoco es exacto decir que «si el nombre de host no coincide del todo, nunca se puede usar». Lo importante es cerrar el uso de la credencial al alcance que el servicio reconoce. Usar orígenes relacionados tampoco es ampliar sin límite la lista de permitidos del servidor.⁹

La «resistencia al phishing» no es resistencia a todo tipo de fraude

La explicación hasta aquí presupone que el navegador, el sistema operativo y el autenticador son de confianza, y que el servidor realiza las verificaciones necesarias. La intrusión en el sitio legítimo, el malware en el dispositivo o un procedimiento débil de recuperación de cuenta no se resuelven solo con WebAuthn.

También puede ocurrir que un sitio falso induzca a «como no se puede usar passkey, introduzca la contraseña y el código SMS» y se use otro camino de inicio de sesión. La passkey es fuerte contra el accidente de entregar la credencial genuina a un sitio falso; no significa que el usuario ya no tenga que prestar ninguna atención.⁵

5. La huella, el rostro y el PIN no son una contraseña enviada al servidor

Si al usar una passkey se pide la huella o el rostro, es para confirmar que la operación de usar la clave privada la aprueba el usuario legítimo de ese dispositivo. Ese proceso se llama verificación de usuario (User Verification, UV). Una respuesta de autenticación WebAuthn no lleva una imagen de huella ni un vector de rasgos faciales al destino del inicio de sesión.¹²

flowchart TB
        accTitle: Comprobación de identidad en el dispositivo y verificación de la firma en el servicio
        accDescr: La huella, el rostro y el PIN se usan del lado del usuario para autorizar el uso de la clave; el servicio no comprueba datos biométricos, sino la firma y el resultado de la verificación.
        A["Confirmar con huella, rostro o PIN"] --> B["El autenticador autoriza el uso de la clave privada"]
        B --> C["Crear una respuesta de autenticación firmada"]
        C --> D["El servicio verifica con la clave pública"]
        D --> E["Comprobar también el resultado de la verificación de usuario pedida"]

Figura 7: El desbloqueo del dispositivo y la autenticación ante el servicio se coordinan, pero el servidor no coteja huellas ni PIN.

Si se puede usar con PIN, puede parecer lo mismo que una contraseña. La diferencia es con qué se coteja ese PIN. Aquí el PIN sirve para autorizar el uso del autenticador; no es una contraseña que el sitio web guarda de todos los usuarios y recibe en cada inicio de sesión. En un autenticador adecuado también opera, por ejemplo, un límite de intentos fallidos.³

Sin embargo, si se roba el dispositivo y se conoce además cómo desbloquearlo, el riesgo de que el atacante use la passkey aumenta. Que se haya pasado a reconocimiento facial no justifica un código de dispositivo fácil. Además, la presencia de usuario (User Presence, UP), que indica un toque en la pantalla u otra acción, y la UV por biometría o PIN son flags distintos. Quien implementa debe exigir la UV necesaria y confirmarla también en la respuesta.

6. Las sincronizadas y las vinculadas al dispositivo protegen sitios distintos

Hay passkeys que se sincronizan entre dispositivos y passkeys ligadas a un autenticador concreto. Ambas autentican sin entregar la clave privada al destino del inicio de sesión, pero el modo de guardar, replicar y restaurar la clave es distinto.¹⁰

flowchart TB
        accTitle: La sincronización y el inicio de sesión son caminos distintos
        accDescr: La sincronizada replica la clave a través de un almacén cifrado, pero lo que se envía al destino del inicio de sesión, tanto en la sincronizada como en la vinculada, es la respuesta de autenticación.
        V["Almacén de sincronización cifrado"] <-->|"Sincronización y restauración"| A["Passkey sincronizada del dispositivo A"]
        V <-->|"Sincronización y restauración"| B["La misma passkey en el dispositivo B"]
        A -->|"Respuesta firmada"| S["Servicio de destino del inicio de sesión"]
        B -->|"Respuesta firmada"| S
        K["Autenticador vinculado"] -->|"Respuesta firmada"| S

Figura 8: Separar el camino de sincronización que replica la clave privada del camino de inicio de sesión hacia el servicio permite entender la diferencia entre ambos.

En los mecanismos de Apple y Google, las passkeys que se sincronizan se protegen con cifrado de extremo a extremo. No es un diseño en el que el proveedor del servicio pueda leer los datos guardados en la nube tal cual y obtener la clave privada.¹¹¹²

En cambio, para restaurar en un dispositivo nuevo puede hacer falta, además de iniciar sesión en la cuenta de sincronización, el bloqueo de pantalla del dispositivo anterior o el PIN del almacén. Las condiciones concretas varían según el producto y la configuración. No se puede decir ni que «con la contraseña de la cuenta en la nube se restauran todas las passkeys» ni que «si se recupera la cuenta en la nube, se restaura siempre».¹¹¹³

En las sincronizadas, si se comprometen también los medios de desbloqueo y recuperación del almacén y los dispositivos participantes, el impacto puede extenderse a varios servicios. Importan la autenticación multifactor de la cuenta de sincronización, un bloqueo fuerte del dispositivo y la gestión de los destinos de recuperación. Si el servicio lo admite, también se considera la protección con una clave de seguridad física. Sin embargo, si hasta la clave de recuperación se deja solo en el mismo dispositivo o en el mismo almacén, se convierte en una configuración en la que se pierde todo junto.

También hay que atender el nivel de garantía de la organización. En NIST SP 800-63B-4, un autenticador sincronizable se puede usar en AAL2 si cumple las condiciones, pero no en AAL3, que no admite la exportación de la clave privada. A la inversa, que sea vinculada al dispositivo no la convierte automáticamente en AAL3: hay que cumplir el resto de requisitos, como la protección por hardware.¹⁴¹⁵

Usar el teléfono mediante un código QR no es lo mismo que sincronizar

También existe el método de leer con el teléfono un código QR mostrado en el PC e iniciar sesión con la passkey de ese teléfono. En la autenticación entre dispositivos de FIDO se confirma la proximidad, por ejemplo con Bluetooth, y la autenticación se hace en el teléfono. No es una operación que copie la clave privada del teléfono al PC.¹⁶¹

flowchart TB
        accTitle: Flujo para iniciar sesión en otro PC con la clave del teléfono
        accDescr: Se lee el QR del PC con el teléfono, se confirma la proximidad y se autentica con la verificación de usuario en el teléfono. No es un flujo que copie la clave privada al PC.
        A["Mostrar el QR en la pantalla de inicio de sesión del PC"] --> B["Leer el QR con el teléfono"]
        B --> C["Confirmar la proximidad entre dispositivos"]
        C --> D["Verificación de usuario y firma en el teléfono"]
        D --> E["El servicio verifica la respuesta de autenticación"]
        E --> F["El inicio de sesión se completa en el PC"]

Figura 9: La autenticación entre dispositivos usa el teléfono de la mano como autenticador y no replica la clave en el PC.

Puede usarse incluso desde un PC que no comparte el mismo destino de sincronización, pero no sirve de reserva si se pierde el teléfono que guarda la clave. Distinga «pude iniciar sesión desde el PC» de «en el PC también hay una passkey independiente registrada».

7. Si se pierde el teléfono, detenga por separado el dispositivo, la credencial y la sesión

Al perderlo, organice desde un dispositivo seguro un bloqueo remoto u otra medida y, si se sospecha un uso indebido, contacte de inmediato con el servicio o con el punto de contacto de la organización. En paralelo, compruebe si puede entrar en la cuenta con una passkey de reserva o un medio de recuperación. No hace falta esperar a que termine la restauración para comunicar la pérdida o suspender el uso. Proteger el dispositivo, proteger la cuenta de sincronización y revocar del lado del servicio tienen papeles distintos.¹⁷¹⁸

flowchart TB
        accTitle: Qué comprobar por separado al perder un dispositivo
        accDescr: Mientras se protege el dispositivo perdido y se contacta con el punto de contacto, se confirma un medio de recuperación seguro. La revocación de la passkey y el cierre de las sesiones existentes se hacen por separado.
        A["Se ha perdido el dispositivo"] --> B["Bloqueo remoto y contacto con el punto de contacto"]
        A --> C["Comprobar claves de reserva y medios de recuperación"]
        B --> D["Detener el uso de la passkey en riesgo"]
        C --> E["Entrar en la pantalla de gestión desde un dispositivo seguro"]
        D --> F["Cerrar también las sesiones existentes por separado"]
        E --> F
        F --> G["Comprobar destinos de sincronización y métodos de autenticación registrados"]
        G --> H["Preparar una clave nueva y una de reserva en un entorno seguro"]

Figura 10: Detener el dispositivo, revocar la passkey y terminar el estado de sesión iniciada son procesos distintos.

Si es vinculada al dispositivo, se puede separar: revocar en el servicio la credencial del autenticador perdido y usar una credencial de reserva registrada por separado. En las sincronizadas, las copias de varios dispositivos son, para el servicio, la misma credencial, así que si se elimina esa credencial del lado del servicio, las copias de los demás dispositivos tampoco podrán iniciar sesión en ese mismo servicio. No cabe contar con que el servicio pueda revocar de forma individual solo la copia de un dispositivo.¹⁰²

Un borrado remoto tampoco se refleja de inmediato si el dispositivo está sin conexión. En «Buscar» de Apple, el borrado de un dispositivo sin conexión empieza la próxima vez que pasa a estar en línea.¹⁹ Es peligroso concluir que, solo por haber quitado el dispositivo de la cuenta de sincronización, la copia de la clave privada que hay en ese dispositivo ha dejado de ser usable con certeza. Si hay preocupación de uso indebido, hay que decidir detener o revocar con rapidez la credencial correspondiente en cada servicio. Si no se puede iniciar sesión, use el canal oficial y, en paralelo, confirme el procedimiento para que el usuario legítimo vuelva.

Además, borrar una passkey no implica, por sí solo, que terminen todas las sesiones existentes. Compruebe por separado una función como «cerrar sesión en todos los dispositivos» del servicio, y también que no se haya añadido una passkey o un destino de recuperación sospechosos.²⁰¹⁸

Antes de perderlo, da tranquilidad comprobar si los servicios importantes admiten registrar varias passkeys, registrar una reserva independiente y probar de verdad que se puede iniciar sesión con ella. Tener la misma clave en dos dispositivos por sincronización es cómodo, pero no es lo mismo que haber registrado otra clave distinta. Antes de eliminar el último medio de inicio de sesión, confirme las vías de vuelta, incluido el destino de custodia de los códigos de recuperación.

8. Dónde quedan los puntos débiles incluso con passkeys

Las passkeys fortalecen una parte importante de la autenticación, pero el camino hacia la cuenta no es solo la pantalla habitual de inicio de sesión. Al introducirlas, además de «si ha aumentado la gente que usa passkeys», revise las vías siguientes.

flowchart TB
        accTitle: Vías de ataque que quedan tras introducir passkeys
        accDescr: Aparte del inicio de sesión con passkey, siguen siendo objetivos un medio alternativo débil, el procedimiento de recuperación, el dispositivo o el almacén, y las sesiones existentes.
        B["Inicio de sesión alternativo débil"] --> A["Acceso no autorizado a la cuenta"]
        C["Abuso del procedimiento de recuperación"] --> A
        D["Compromiso del dispositivo o del almacén"] --> A
        E["Abuso de la sesión"] --> A

Figura 11: Aunque el inicio de sesión habitual con passkey sea fuerte, las demás entradas y el estado posterior al inicio de sesión hay que protegerlos por separado.

Inicio de sesión alternativo. Si las mismas operaciones se pueden hacer solo con contraseña o SMS, el atacante puede apuntar ahí. Ahora bien, desactivarlas todas de golpe antes de confirmar reservas y recuperación también cierra la puerta a los usuarios legítimos. Prepare dispositivos compatibles, claves de reserva y procedimientos de soporte, acote el alcance y reduzca por etapas.⁵

Recuperación de cuenta y adición de claves. Relajar la comprobación de identidad solo con la declaración de que «se me rompió el dispositivo» se convierte en una vía para registrar la passkey del propio atacante. En las cuentas importantes, combine la comprobación de la solicitud de recuperación, la reautenticación al añadir o quitar un método de autenticación, las notificaciones de cambio y la auditoría. Emitir una notificación no basta para impedir un registro no autorizado: la comprobación tiene que ser anterior al registro.¹⁸

Dispositivo y almacén de sincronización. Siguen haciendo falta las actualizaciones del sistema operativo y del navegador, el bloqueo del dispositivo y saber qué dispositivos participan en el almacén. La passkey no es una función que convierta un PC inseguro en uno seguro. En un dispositivo compartido, compruebe también quién puede usar la credencial según la configuración.

Sesión. Si una cookie de sesión habitual se puede robar y usar, el atacante a veces puede operar sin una nueva autenticación con passkey. Diseñe por separado Secure, HttpOnly, un SameSite adecuado, la vigencia, la reautenticación y la revocación del lado del servidor. HttpOnly restringe que JavaScript lea la cookie, pero no impide que un XSS abuse de una sesión ya iniciada.²⁰

9. Puntos clave al introducirlas en un servicio web propio

Llamar a la API no completa la implementación del inicio de sesión

La API de registro de WebAuthn es navigator.credentials.create() y la de autenticación, navigator.credentials.get(). FIDO2 se compone de WebAuthn y CTAP, y CTAP es la especificación para el intercambio entre el cliente y un autenticador como una clave de seguridad externa. Quien implementa un servicio web no tiene que construir por sí mismo la comunicación USB o Bluetooth.²¹

flowchart TB
        accTitle: Reparto de la implementación de passkeys en un servicio web
        accDescr: El servidor emite las peticiones y verifica las respuestas, el navegador ofrece la API y el autenticador usa la clave.
        S["Servidor: emisión de peticiones y verificación de respuestas"] <-->|"Peticiones y respuestas"| B["Navegador: API WebAuthn"]
        B <--> O["Coordinación con el sistema operativo y el administrador de credenciales"]
        B <-->|"CTAP, etc."| A["Autenticador externo"]

Figura 12: Implemente como un conjunto la llamada en el navegador y la verificación y la gestión de cuentas en el servidor.

Lo que sigue es el esqueleto del lado del navegador, que indica dónde van los valores que se pasan a la API. Este fragmento, por sí solo, no completa el registro ni el inicio de sesión. registrationOptions y authenticationOptions son valores que el servidor ha creado para este intento, y los elementos binarios como challenge, user.id y el identificador de credencial se dan por convertidos a la secuencia de bytes adecuada, no dejados como las cadenas Base64URL del JSON.²

// Llamar desde la operación del botón de registro. El servidor emite y guarda las opciones.
async function createPasskey(registrationOptions) {
  if (!window.isSecureContext || !window.PublicKeyCredential) {
    throw new Error("En este entorno no se pueden usar passkeys.");
  }
  const credential = await navigator.credentials.create({
    publicKey: registrationOptions,
  });
  if (!credential) throw new Error("No se completó el registro de la passkey.");
  return credential;
  // El llamador serializa la respuesta de registro y la envía al servidor.
  // No mostrar el registro como completado hasta que la verificación del servidor tenga éxito.
}

// Flujo de autenticación habitual, llamado desde la operación del botón de inicio de sesión.
async function usePasskey(authenticationOptions) {
  if (!window.isSecureContext || !window.PublicKeyCredential) {
    throw new Error("En este entorno no se pueden usar passkeys.");
  }
  const assertion = await navigator.credentials.get({
    publicKey: authenticationOptions,
  });
  if (!assertion) throw new Error("No se completó la autenticación con passkey.");
  return assertion;
  // El llamador serializa la respuesta de autenticación y la envía al servidor.
  // El servidor verifica y solo entonces crea la sesión.
}

En una pantalla real, el llamador trata la Promise rechazada y explica la cancelación, el tiempo de espera, un entorno no compatible, etc. Para la conversión binaria de la respuesta de registro y para la comunicación, usar las API correspondientes de la biblioteca adoptada reduce los olvidos de implementación.

En las opciones de registro, authenticatorSelection.residentKey: "required" es el ajuste que pide una credencial descubrible con la que se puede elegir la cuenta. En un diseño que hace obligatoria la confirmación por biometría o PIN, se especifica authenticatorSelection.userVerification: "required" en el registro y userVerification: "required" en la autenticación. user.id debe ser un identificador opaco de 64 bytes como máximo emitido por el servidor; no use la dirección de correo en sí, y distíngalo del nombre para mostrar.⁷

Si usa Conditional UI, que ofrece la passkey como sugerencia de autocompletado en el campo de inicio de sesión, compruebe la compatibilidad con PublicKeyCredential.isConditionalMediationAvailable() y combine mediation: "conditional" con autocomplete="username webauthn" en el campo. Para entornos no compatibles, conserve el flujo habitual desde un botón como el de arriba.²²

Diseñe primero lo que el servidor verifica

Para verificar la parte criptográfica se pueden usar bibliotecas como SimpleWebAuthn en Node.js o fido2-net-lib en .NET. Tener una biblioteca, no obstante, no hace automáticamente seguros el vínculo con la cuenta ni el diseño de la recuperación.²³²⁴

Esta tabla es un conjunto de puntos de comprobación de la implementación, no un sustituto del procedimiento de verificación de la especificación. Si se usan iframes u orígenes relacionados, compruebe también esas condiciones adicionales. En la autenticación explícita habitual, compruebe UP y, si hizo obligatoria la UV, compruebe también la UV de la respuesta.⁷⁸

flowchart TB
        accTitle: Decisión de autenticación del lado del servidor
        accDescr: Se emite la sesión solo después de comprobar la correspondencia con la petición actual, el destino de uso, el titular de la credencial, y la firma y la directiva.
        A["Se recibe la respuesta de autenticación"] --> B{"¿Coincide con esta petición no usada?"}
        B -->|"Sí"| C{"¿El destino de uso y la cuenta titular son correctos?"}
        C -->|"Sí"| D{"¿La firma y los resultados de verificación necesarios son correctos?"}
        D -->|"Sí"| E["Consumir la petición una sola vez y emitir la sesión"]
        B -->|"No"| X["Rechazar la autenticación"]
        C -->|"No"| X
        D -->|"No"| X

Figura 13: Confirme tanto que la firma es correcta como que esta vez se puede permitir el inicio de sesión en esa cuenta.

signCount tampoco es un detector universal de clones. Hay autenticadores que no tienen contador y devuelven 0, y hay razones distintas de la duplicación para que el valor no aumente de forma monótona. Compruebe el trato en los entornos adoptados, incluidas las sincronizadas, y en la biblioteca, y use los valores anómalos como insumo de una decisión de riesgo. Evite juicios uniformes del tipo «si es menor o igual que la vez anterior, es un clon» o «si es 0, es seguro».⁸

En el entorno de verificación, separe el requisito de contexto seguro de WebAuthn y el requisito de RP ID. Por lo general hace falta HTTPS, y para desarrollo se puede usar http://localhost. Que http://127.0.0.1 se trate como un origen potencialmente de confianza y que una dirección IP pueda ser un RP ID son cosas distintas. Como el RP ID de WebAuthn tiene condiciones de nombre de dominio, verifique también en desarrollo con una configuración que el navegador acepte, como localhost. Las credenciales creadas ahí no se pueden llevar tal cual al dominio de producción.⁹²⁵

10. Qué comprobar en Windows y en los sistemas internos

En Windows, lo importante es no concluir, solo por la observación de que «apareció la pantalla de Windows Hello», el destino de almacenamiento de la passkey ni si se sincroniza. La verificación de usuario con Windows Hello y el guardado y la sincronización en un administrador de credenciales de Microsoft o de otro proveedor son puntos a comprobar por separado. Hay passkeys que se guardan en local y passkeys que se guardan en un proveedor de sincronización.²⁶

flowchart TB
        accTitle: Orden de comprobación al introducir passkeys en Windows
        accDescr: Se comprueban por separado, en este orden, el destino del inicio de sesión, dónde se guarda la credencial, la directiva de permiso de la organización y la recuperación en caso de pérdida.
        A["¿En qué se inicia sesión?"] --> B["Distinguir servicio web, Entra ID y Windows"]
        B --> C["Comprobar el destino de almacenamiento de la passkey y si se sincroniza"]
        C --> D["Comprobar la directiva de métodos de autenticación y la intensidad de autenticación"]
        D --> E["Probar las claves de reserva y el procedimiento en caso de pérdida"]

Figura 14: Aunque la pantalla de Windows Hello sea la misma, el significado operativo cambia según el destino del inicio de sesión y el destino de almacenamiento.

Las credenciales que se conservan en el contenedor local de Windows Hello no son lo mismo que un almacén sincronizado. En una configuración de Windows Hello que usa TPM, la protección de la clave por el TPM desempeña un papel importante. Aun así, no identifique la clasificación general de las passkeys con la presencia o no de TPM; juzgue por el destino de almacenamiento real, el dispositivo y los requisitos de la organización.²⁷²⁸

En Microsoft Entra ID, diseñe por separado la directiva de métodos de autenticación que permite el uso de passkeys y la intensidad de autenticación de acceso condicional, que decide qué fortaleza de autenticación exige un recurso. Solo con dejar el estado en el que se puede registrar una passkey, no todo el acceso queda limitado automáticamente a MFA resistente al phishing. Qué tipos de passkey se permiten, incluidas las sincronizadas, se confirma con el estado de compatibilidad más reciente y con la directiva de la organización.²⁹

Si se hace que una aplicación web interna admita WebAuthn de forma directa, primero se ponen en orden HTTPS, certificados, resolución de nombres y un nombre de dominio que sea un RP ID estable. Si se delega el proceso en una plataforma de identidad, del lado de la aplicación se diseña la integración con esa plataforma y la gestión de sesiones. Usar Entra ID desde una aplicación WinForms/WPF y que la propia aplicación sea un RP de WebAuthn tampoco son el mismo asunto.

Además, las passkeys no son una función que sustituya automáticamente la autenticación a un recurso compartido SMB ni que corrija de forma directa los problemas de NTLM o Kerberos. Decidir qué inicio de sesión se cambia y probar primero, en un alcance pequeño, el registro, la autenticación, la pérdida y la recuperación es lo que lleva a una introducción que no detiene el negocio.

11. Resumen — No entregar el secreto y proteger lo que lo rodea van juntos

La fortaleza de la passkey está en autenticar con una firma ligada a la petición actual y al destino de uso, sin entregar la clave privada al servicio en el que se inicia sesión. Con la filtración de la clave pública sola no se puede fabricar una firma correcta, y desde un sitio falso no relacionado no se puede usar la credencial del sitio genuino.

Al mismo tiempo, hay que seguir protegiendo el almacén sincronizado, el bloqueo del dispositivo, los inicios de sesión alternativos, el procedimiento de recuperación y la sesión posterior al inicio de sesión. Separar las medidas que dejan de ser necesarias al pasar a passkeys de las que siguen siendo necesarias es la perspectiva para evaluar bien una introducción.

Si es usuario, compruebe el destino de almacenamiento y los medios de recuperación, y prepare una reserva independiente para las cuentas importantes. Si introduce, diseñe como una sola función la verificación en el servidor, la gestión de varias passkeys y la revocación y la recuperación. Incluir eso es lo que conecta la comodidad y la resistencia al phishing con la operación real.

Artículos relacionados

• Qué es el TPM de Windows — El «caja fuerte que no deja salir las claves» y el arranque medido, ilustrados
• NTLM y Kerberos ilustrados — Por qué la autenticación «cae» a NTLM
• Incorporar autenticación Entra ID a aplicaciones WinForms/WPF — Configuración práctica con MSAL.NET y el agente WAM
• Trato seguro de credenciales en PowerShell — Expulsar las contraseñas en claro de los scripts
• Lista mínima de comprobación de seguridad para el desarrollo de aplicaciones Windows
• Por dónde empezar la seguridad en una pyme — Cómo recorrer la «Guía de medidas de seguridad de la información para pymes» de IPA, 4.ª edición

Áreas de consultoría relacionadas

En KomuraSoft LLC nos ocupamos de Custom Software Development que incluye la revisión de la autenticación de sistemas web internos, la integración con Entra ID y la incorporación de autenticación a aplicaciones de negocio de Windows como WinForms y WPF. También al considerar la compatibilidad con passkeys, ordenamos no solo la pantalla de inicio de sesión, sino los dispositivos de uso, la plataforma de autenticación existente y el procedimiento de recuperación.

Referencias

Las especificaciones y la información de producto se han comprobado a 8 de septiembre de 2026. Las funciones disponibles varían según el navegador, el sistema operativo y la configuración del inquilino.

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

¿Por qué las passkeys son más seguras que las contraseñas?

Porque autentican con una firma ligada al desafío actual y al sitio donde se usa, sin entregar nunca la clave privada al servicio en el que se inicia sesión. La filtración de la clave pública sola no permite a un atacante falsificar una firma, y una passkey pensada para el sitio genuino no se puede usar desde un sitio falso no relacionado. Aun así, el servidor tiene que realizar la verificación adecuada, y el dispositivo, los medios de recuperación y la sesión siguen teniendo que protegerse.

¿Se envían al sitio los datos de huella o de rostro?

Una respuesta de autenticación WebAuthn nunca lleva una imagen de huella ni un vector de rasgos faciales al servicio en el que se inicia sesión. La biometría y el PIN se usan del lado del usuario para autorizar el uso de la clave privada, mientras que el servicio comprueba la firma y el resultado de la verificación de usuario.

Si la clave privada no se envía, ¿cómo puede sincronizarse una passkey?

Porque la autenticación ante el servicio y la sincronización del administrador de credenciales son dos caminos distintos. Una passkey sincronizada cifra la clave privada y la replica entre dispositivos, pero eso no es entregar la clave privada al servicio en el que se inicia sesión. Las condiciones para desbloquear y restaurar el almacén de sincronización varían según el producto y la configuración.

Si pierdo el teléfono, ¿qué ocurre con las cuentas que usan passkeys?

Con una passkey sincronizada puede usarse en otro dispositivo si se cumplen las condiciones de recuperación del almacén, y con una vinculada al dispositivo hace falta una credencial de reserva registrada por separado o un medio de recuperación. Mientras asegura el dispositivo y comunica la pérdida, compruebe que tiene una vía segura de recuperación, y trate la revocación de la credencial en riesgo y el cierre de las sesiones existentes como dos pasos distintos. Si el servicio revoca la misma credencial sincronizada, las copias de los demás dispositivos tampoco podrán iniciar sesión en ese servicio.

¿Las passkeys hacen innecesarias las medidas contra el phishing?

No. Las passkeys son fuertes contra la entrega de credenciales a un dominio falso, pero ser inducido a pasar a una contraseña o a SMS, el abuso del procedimiento de recuperación y el compromiso del dispositivo o de la sesión siguen necesitando sus propias medidas.

¿Una passkey usada con Windows Hello está siempre vinculada al dispositivo?

La pantalla de confirmación de Windows Hello, por sí sola, no dice dónde está guardada la credencial ni si se sincroniza. Distinga las credenciales del contenedor local de las passkeys guardadas en un proveedor de sincronización, y compruebe el destino de almacenamiento real, el dispositivo y la directiva de la organización.

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.