¿Por qué las passkeys son seguras? — El mecanismo de la «autenticación que no envía secretos», explicado con diagramas

Ya nadie se sorprende con la noticia de que «otra gran plataforma sufrió una filtración de contraseñas». Aunque se hagan simulacros de phishing todos los años, el número de personas que caen en la trampa nunca llega a cero. «No reutilice contraseñas, hágalas largas, el cambio periódico… ya no hace falta»: incluso las recomendaciones han cambiado de rumbo varias veces.

La passkey, que se ha extendido con rapidez en los últimos años, es el método de autenticación que Apple, Google y Microsoft impulsan conjuntamente como respuesta a esta situación.¹ Suele presentarse como «cómodo, porque permite iniciar sesión con la huella o el rostro», pero eso no es lo esencial. El verdadero valor de la passkey está en que traslada el fundamento de la seguridad de la «atención humana» a la «estructura del protocolo».

• Las contraseñas se filtran por descuido del usuario, así que hay que capacitar → los humanos siempre se equivocan
• Hay que entrenar a la gente para reconocer sitios falsos → se pueden crear sitios falsos indetectables
• Con la passkey → no hay ningún secreto que enviar, y en un sitio falso la firma no puede formarse

En este artículo explicamos con diagramas por qué las passkeys son seguras, partiendo de qué es exactamente lo que falla en las contraseñas. A partir de ahí, respondemos de frente a las preguntas obvias de «¿son realmente seguras las passkeys sincronizadas?» y «¿no tienen puntos débiles?», y al final repasamos los puntos prácticos clave para implementarlas en aplicaciones web y en entornos Windows.

1. Primero, la conclusión

Las razones por las que las passkeys son seguras se resumen en estas tres.

1. No existe ningún secreto en el servidor. Lo único que el servidor almacena es la clave pública, una información que no se puede explotar aunque se filtre. Aunque toda la base de datos se filtre por completo, el atacante no se lleva ningún «material para suplantar la identidad».²
2. El secreto no circula por la red. Lo único que se envía al iniciar sesión es la firma de un número aleatorio de un solo uso (el desafío). Como la clave privada nunca sale del autenticador del dispositivo, ni interceptando ni retransmitiendo en ningún punto de la ruta se puede obtener el secreto.²
3. En un sitio falso, la firma no puede formarse. La passkey está vinculada al dominio del sitio, y el navegador impone la verificación de ese dominio. Aunque el usuario caiga en un sitio falso, la passkey del sitio genuino ni siquiera aparece entre las opciones, y aunque se retransmitiera la firma, la verificación la rechazaría.³

Estas tres razones no son ingeniosidades independientes, sino consecuencias que se derivan todas de un único cambio de diseño: la transición de una autenticación que “comparte y envía un secreto” a una que “demuestra mediante una firma que se posee el secreto”. Vamos a verlas una por una.

Relación de términos — Passkey, WebAuthn, FIDO2 y CTAP

Este ámbito tiene muchos términos, y además su alcance varía según el artículo, así que primero conviene aclarar solo la relación entre ellos. La passkey no es un protocolo nuevo, sino un «nombre» que se le puso a una combinación de estándares ya existentes.²¹

Tabla 1: la passkey es un nombre que se apoya sobre la base de FIDO2, no el nombre de un estándar en sí

En otras palabras, «dar soporte a passkeys», traducido al lenguaje de la implementación, significa «implementar WebAuthn». CTAP es la capa de la que se encargan el navegador y el sistema operativo cuando se usa un autenticador externo, así que quien desarrolla la aplicación web nunca la toca directamente.

2. ¿Qué es exactamente lo que falla en la autenticación por contraseña?

El atajo para entender la seguridad de las passkeys es identificar las debilidades de la contraseña por «ubicación». En la autenticación por contraseña, el secreto mismo recorre todo el trayecto cada vez que se autentica.

sequenceDiagram
    participant U as Usuario
    participant B as Navegador
    participant S as Servidor
    Note over U: Guarda el secreto (la contraseña) en su mente<br/>【Debilidad 1】Se puede adivinar y se reutiliza
    U->>B: Introduce la contraseña
    Note over B: 【Debilidad 2】Puede introducirse igual<br/>en un sitio falso (indistinguible a simple vista)
    B->>S: Envía la contraseña tal cual
    Note over B,S: 【Debilidad 3】El secreto circula por la red<br/>TLS lo protege, pero vuelve a texto plano en el destino
    S->>S: Coteja con el hash almacenado
    Note over S: 【Debilidad 4】Se acumulan los secretos (hashes) de todos los usuarios<br/>Si se filtran, son blanco de fuerza bruta sin conexión

Figura 1: en la autenticación por contraseña, el secreto mismo existe en todo el trayecto

Desde el punto de vista de un atacante, esta es una estructura con muchos blancos fáciles de alcanzar.

• Debilidad 1 (el usuario): solo tiene la fortaleza que se puede memorizar y se reutiliza en varios sitios. Una filtración en un solo lugar se propaga a todas las cuentas (ataque de lista de credenciales o credential stuffing).
• Debilidad 2 (el momento de la introducción): si se prepara un sitio falso indistinguible del real, el usuario entrega el secreto por su propia voluntad (phishing).
• Debilidad 3 (la ruta): con TLS, interceptar la ruta en sí es difícil, pero de nada sirve si se interpone un «punto de retransmisión con apariencia legítima» (el AiTM que se explica más adelante).
• Debilidad 4 (el servidor): aunque se almacene en forma de hash, si la base de datos se filtra puede someterse a fuerza bruta sin conexión. Las contraseñas más débiles caen primero.

«Entonces, ¿no bastaría con añadir un código de un solo uso (SMS o TOTP)?» es la idea detrás de la autenticación multifactor tradicional, pero esta tampoco cambia la estructura de enviar un secreto compartido. El TOTP hace que el servidor y la aplicación de autenticación compartan la misma semilla (secreto), y el código de seis dígitos generado el usuario termina pudiendo introducirlo igualmente en un sitio falso. De hecho, el phishing de tipo AiTM (Adversary-in-the-Middle), en el que el sitio falso retransmite en tiempo real hacia el servidor real, logra su objetivo con solo desviar tal cual el par de contraseña y código de un solo uso. Por eso CISA (la agencia de ciberseguridad de Estados Unidos) solo cita dos métodos como «MFA resistente al phishing»: el método FIDO/WebAuthn y la autenticación basada en PKI como las tarjetas inteligentes (PIV/CAC), y coloca a FIDO como el estándar de oro entre ambos.⁴

En definitiva, el problema no está en la «fortaleza» de la contraseña, sino en la propia estructura de “compartir el secreto y enviarlo cada vez que se autentica”.

3. La verdadera naturaleza de la passkey — demostrar que se posee el secreto sin enviarlo

La passkey es una credencial basada en criptografía de clave pública que se apoya sobre dos estándares: WebAuthn del W3C y CTAP de la FIDO Alliance (juntos, FIDO2).²¹ Suena complicado, pero la estructura es simple.

flowchart LR
    subgraph DEV["Dispositivo del usuario"]
        AUTH["Autenticador (caja fuerte)<br/>Windows Hello / Face ID /<br/>bloqueo de pantalla de Android / llave de seguridad"]
        SK["Clave privada<br/>nunca sale de aquí"]
        BIO["Huella, rostro o PIN<br/>= solo abren la puerta de la caja fuerte<br/>tampoco salen al exterior"]
        AUTH --- SK
        BIO -->|"Verificación local"| AUTH
    end
    subgraph SRV["Servidor"]
        PK["Clave pública<br/>no se puede explotar aunque se filtre<br/>información 'solo para verificar'"]
    end
    SK -.->|"Par matemático<br/>(el lado que crea la firma)"| PK

Figura 2: en esencia, la passkey es un par de claves por sitio. El lado secreto nunca sale del dispositivo, y el servidor solo tiene la clave pública para verificar

• La clave privada es la clave capaz de crear la firma; se guarda en el autenticador del dispositivo (Windows Hello, Face ID/Touch ID del iPhone, el bloqueo de pantalla de Android, o una llave de seguridad como YubiKey) y nunca sale de ahí.
• La clave pública es la clave que solo puede verificar la firma, y esta es la que se deposita en el servidor. Calcular la clave privada a partir de la clave pública es computacionalmente inviable, así que es información que no importa que se filtre.
• Los datos biométricos, como la huella o el rostro, se usan únicamente para abrir localmente la puerta de la caja fuerte, y tampoco salen del dispositivo. Nunca se envían datos biométricos al servidor.¹

Registro: se entrega «solo» la clave pública

Este es el flujo al registrar una passkey en un sitio.

sequenceDiagram
    participant S as Servidor (example.com)
    participant B as Navegador
    participant A as Autenticador
    S->>B: Solicitud de registro (desafío aleatorio + información del sitio)
    B->>A: Crea una clave para este sitio (example.com)
    A->>A: Verifica la identidad con huella, rostro o PIN (local)
    A->>A: Genera un nuevo par de claves<br/>la clave privada se guarda internamente
    A->>B: Clave pública + credential ID (la etiqueta de la clave)
    B->>S: Envía la clave pública + credential ID
    S->>S: Guarda la clave pública para esta cuenta
    Note over S: Lo único que recibió el servidor fue<br/>«información que no se puede explotar aunque se filtre»

Figura 3: durante el registro, lo único que circula por la red y que el servidor almacena es la clave pública

Lo importante es que, en este momento, el par de claves se crea vinculado al dominio del sitio (RP ID). Una passkey creada para example.com solo puede usarse en el sitio example.com (como el RP ID se maneja a nivel de dominio, puede usarse desde páginas de subdominios bajo el mismo dominio, como login.example.com, pero no desde un dominio sin relación). Esta vinculación es la base de la resistencia al phishing que se explica más adelante.³

Además, el par de claves se crea nuevo cada vez, para cada sitio. Como la passkey del sitio A y la del sitio B no tienen relación matemática entre sí, el concepto mismo de «reutilización» no existe, y tampoco sirven como dato para correlacionar al usuario entre distintos sitios.

Autenticación: se devuelve una firma de un solo uso

Este es el flujo al iniciar sesión. Compárelo con la autenticación por contraseña (Figura 1).

sequenceDiagram
    participant S as Servidor (example.com)
    participant B as Navegador
    participant A as Autenticador
    S->>B: Solicitud de inicio de sesión (desafío aleatorio de un solo uso)
    B->>A: Solicita una firma para example.com
    A->>A: Verifica la identidad con huella, rostro o PIN (local)
    A->>A: Crea la firma con la clave privada<br/>incorpora el desafío + el origen + el hash del RP ID
    A->>B: Firma (no es la clave privada en sí)
    B->>S: Envía la firma
    S->>S: Verifica la firma con la clave pública almacenada<br/>y también comprueba el desafío, el origen y el RP ID
    Note over B,S: Por la ruta solo circula una firma de un solo uso<br/>aunque se robe, no sirve para el próximo desafío

Figura 4: tampoco en la autenticación se desplaza el secreto. Lo que circula es solo un «documento de prueba de un solo uso»

El servidor plantea cada vez un nuevo número aleatorio (el desafío), y el autenticador firma sobre «ese desafío + el origen que el navegador está viendo en ese momento + el hash del RP ID». El servidor verifica la firma con la clave pública que tiene almacenada, y confirma que el desafío es el que él mismo planteó y que el origen y el RP ID corresponden a su propio sitio.⁵

Como consecuencia de este diseño, dos de las tres razones mencionadas al principio ya quedan establecidas.

• No hay secreto en el servidor: lo único almacenado es la clave pública. Aunque se filtre, el atacante no puede crear una firma, así que, a diferencia del hash de una contraseña, no puede «llevárselo y descifrarlo».
• El secreto no circula: aunque se robe la firma en tránsito, como el desafío es de un solo uso, no puede reutilizarse (repetirse).

La razón restante, «en un sitio falso la firma no puede formarse», es el mayor atractivo de la passkey. La veremos en una sección aparte.

4. Por qué el phishing no puede funcionar «por estructura»

El phishing contra contraseñas tiene éxito porque el usuario puede introducir el secreto real en un sitio falso. Un ser humano no distingue (sobre todo si está cansado) entre example.com y examp1e.com, pero el campo de entrada de contraseña funciona igual en cualquiera de los dos sitios.

Con la passkey, esta comprobación no la hace el ser humano, sino el navegador de forma mecánica. Según la especificación de WebAuthn, el navegador solo puede invocar al autenticador cuando «el dominio del origen que se muestra en ese momento» corresponde al «RP ID de la passkey».³ El siguiente diagrama muestra qué ocurre en el momento en que se accede a un sitio falso.

sequenceDiagram
    participant U as Usuario
    participant B as Navegador
    participant P as Sitio falso (examp1e.com)<br/>proxy AiTM que retransmite al real
    participant S as Servidor real (example.com)
    U->>P: Accede a una pantalla de inicio de sesión idéntica en apariencia
    P->>S: (por detrás) Inicia el proceso de inicio de sesión real
    S->>P: Desafío
    P->>B: Desvía el desafío y solicita la firma
    B->>B: El origen actual es examp1e.com<br/>no puede ofrecer la passkey de example.com como candidata
    B--xP: No se crea ninguna firma (el usuario no tiene forma de ser engañado)
    Note over B,S: Aunque se creara una firma por algún método,<br/>como en ella queda incorporado examp1e.com,<br/>la verificación del servidor real siempre la rechazará

Figura 5: el phishing de tipo AiTM logra vulnerar la contraseña más el código de un solo uso, pero con passkeys no llega ni a formarse la firma

Observe que la defensa está duplicada.

1. No aparece entre las opciones: el navegador solo enumera las passkeys cuyo RP ID corresponde al origen. En el dominio falso, la passkey del sitio genuino no aparece como opción, así que el usuario ni siquiera puede «usarla por descuido».
2. La firma no pasa la verificación: lo que se firma incluye el hash del origen y del RP ID confirmados por el navegador. El servidor real coteja esto al verificar, por lo que una firma creada en un origen distinto siempre se rechaza.⁵

Las medidas contra el phishing para contraseñas dependían del esfuerzo humano de que «el usuario mire bien la URL». Con la passkey, el usuario nunca necesita detectar el sitio falso, para empezar. Este es el significado preciso del término «resistente al phishing» (phishing-resistant), y la razón por la que CISA y el NIST (Instituto Nacional de Estándares y Tecnología de Estados Unidos) dan un trato especial al método FIDO/WebAuthn.⁴⁶

A continuación, resumimos lo anterior por tipo de ataque.

Tabla 2: comparación de resistencia por tipo de ataque. En la passkey, cada «○» procede de la estructura, no de la operación ni de la vigilancia del usuario

5. ¿Son seguras las «passkeys sincronizadas»?

Tras leer la explicación hasta aquí, surge naturalmente esta duda: «dijeron que la clave privada nunca sale del dispositivo, entonces ¿por qué una passkey creada en un iPhone también funciona en un iPad?». Es una buena pregunta, y la respuesta es que «existen dos tipos de passkeys».

Adelantamos la conclusión en una tabla de referencia rápida. Lea esta sección y la siguiente como una explicación de por qué cada fila de esta tabla es así.

Tabla 3: referencia rápida entre el tipo sincronizado y el vinculado al dispositivo. La elección depende de si se prioriza la “resistencia a la pérdida” o la “capacidad de controlar dónde está la clave”

flowchart TB
    subgraph SYNC["Passkey sincronizada (opción por defecto para consumidores)"]
        S1["Llavero de iCloud /<br/>Administrador de contraseñas de Google /<br/>gestores de contraseñas como 1Password"]
        S2["Se sincroniza cifrada de extremo a extremo<br/>entre dispositivos de la misma cuenta<br/>ni siquiera el proveedor puede leer el contenido"]
        S3["Ventaja: resistente al cambio de equipo y a la pérdida<br/>Atención: se necesita proteger bien la cuenta en la nube"]
        S1 --> S2 --> S3
    end
    subgraph BOUND["Passkey vinculada al dispositivo"]
        B1["Llave de seguridad (YubiKey, etc.) /<br/>Windows Hello /<br/>Microsoft Authenticator (Entra ID)"]
        B2["La clave privada no sale<br/>físicamente de ese hardware (protegida por TPM, etc.)"]
        B3["Ventaja: la ubicación de la clave es única y clara<br/>Atención: es obligatorio registrar varias, previendo la pérdida"]
        B1 --> B2 --> B3
    end
    SYNC ~~~ BOUND

Figura 6: tipo sincronizado y tipo vinculado al dispositivo. En ambos, «la clave privada nunca se envía al servidor» es igual; lo que cambia es dónde se pone el foco de la protección

La passkey sincronizada es aquella en la que el llavero de iCloud o el Administrador de contraseñas de Google sincronizan la clave privada entre los dispositivos de la misma cuenta. Lo importante aquí es que la sincronización está cifrada de extremo a extremo. Tanto Apple como Google declaran explícitamente que la passkey se cifra en el dispositivo antes de sincronizarse, y que ni siquiera el propio proveedor puede leer su contenido.⁷⁸ Es decir, el principio de que «la clave privada nunca sale del dispositivo» se relaja, con más precisión, a «la clave privada nunca sale del dispositivo en texto plano», y a cambio se obtiene resistencia frente al cambio de equipo o la pérdida.

Conviene dejar bien expresado cómo cambia el modelo de amenazas esta relajación. El lugar que hay que proteger se concentra, de “el servidor de cada sitio”, en “una sola cuenta en la nube”. Se mantiene la misma resistencia frente a filtraciones de base de datos o phishing en cada sitio, pero ahora la toma de control de la propia cuenta de Apple ID o Google se convierte en el punto único de fallo. Por eso es una condición imprescindible aplicar la máxima protección (un bloqueo de pantalla robusto, organizar bien los medios de recuperación y, si es posible, una llave de seguridad física) a la cuenta de la plataforma en la que se depositan las passkeys. El NIST también publicó en abril de 2024 el suplemento de NIST SP 800-63B (Supplement 1: Incorporating Syncable Authenticators Into NIST SP 800-63B), y estableció formalmente que este tipo de passkey sincronizada (syncable authenticator), si cumple los requisitos, puede satisfacer el AAL2 (Authenticator Assurance Level 2, nivel de garantía de autenticador 2) de la norma gubernamental. Sin embargo, dado que la clave privada puede llegar a exportarse, se establece que el tipo sincronizado no debe usarse para el AAL3, que exige un entorno aislado por hardware.⁶

La passkey vinculada al dispositivo es el tipo en el que la clave privada nunca sale del hardware. Una llave de seguridad como YubiKey es el ejemplo típico, y en el ámbito corporativo, la passkey de Microsoft Entra ID (la que se crea dentro de Microsoft Authenticator) también es de este tipo.⁹ El propio Windows Hello de Windows, si hay un TPM disponible, protege la clave privada bajo ese TPM. El mecanismo mismo de esta «caja fuerte de hardware que no deja salir la clave» comparte la misma base que la que explicamos en detalle en el artículo sobre el TPM.

Por cierto, quizá le haya extrañado alguna vez tener que escanear un código QR al «iniciar sesión en el navegador de un PC usando la passkey del móvil». Eso no es una simple transición de pantalla: es el método híbrido (autenticación cross-device de FIDO) que confirma por Bluetooth la proximidad física entre el móvil y el PC. Esta confirmación de proximidad neutraliza el ataque en el que un atacante remoto haría que otra persona aprobara, a través de un código QR, el inicio de sesión en su propio PC.¹

6. No es una bala de plata — las debilidades no «desaparecen», se «desplazan»

Hasta aquí hemos explicado la fortaleza de la passkey, pero, para ser honestos, la passkey no elimina los ataques, sino que es una tecnología que empuja al atacante hacia lugares más débiles. El siguiente diagrama muestra hacia dónde se desplaza el atacante cuando la puerta de entrada de la autenticación se vuelve más sólida.

flowchart LR
    A["Atacante"]
    G["La autenticación en sí<br/>Firma del desafío<br/>【Sólida】"]
    R["Flujo de recuperación de cuenta<br/>Declara 'perdí mi passkey',<br/>fuerza un restablecimiento por SMS o correo<br/>y registra la passkey del atacante"]
    F["Respaldo que coexiste<br/>Si quedan la contraseña o el inicio<br/>de sesión por SMS, ahí está el eslabón más débil"]
    C["Cuenta en la nube<br/>en el tipo sincronizado, Apple ID o<br/>la cuenta de Google es el punto único de fallo"]
    SS["Sesión<br/>robar la cookie tras el inicio de sesión<br/>no depende del método de autenticación"]
    A --x G
    A --> R
    A --> F
    A --> C
    A --> SS

Figura 7: cuando la puerta de entrada (la autenticación) se endurece, el ataque se desplaza al flujo de recuperación, a los medios que coexisten, a la cuenta en la nube y a la sesión

En la práctica hay cuatro riesgos residuales que conviene tener presentes.

1. El respaldo que coexiste se convierte en el eslabón más débil. Si solo se habilita la passkey «además» de lo demás y siguen existiendo la contraseña o el inicio de sesión por SMS, el atacante simplemente usará esos otros medios. Vista la cuenta en su conjunto, la resistencia al phishing queda limitada al nivel del medio de inicio de sesión más débil. El objetivo central de la implementación no es añadir la passkey, sino reducir y eliminar de forma planificada los medios de respaldo.
2. El flujo de recuperación se convierte en una nueva superficie de ataque. Es la táctica de mentir diciendo que «perdió el dispositivo» para llevar el caso a la mesa de soporte o a un restablecimiento por correo, y hacer que se registre la passkey del propio atacante. De hecho, la ingeniería social que engaña a la mesa de ayuda para sortear una autenticación robusta se ha convertido en un recurso habitual en brechas de gran escala. Cuanto más se refuerza la autenticación, más importa cómo se diseñe la verificación de identidad en el flujo de recuperación.
3. En el tipo sincronizado, la cuenta en la nube es el punto único de fallo. Tal como se explicó en la sección anterior. Hace falta tanto proteger la cuenta en la que se depositan las passkeys como, si se usa en una organización, definir la política de «a qué plataforma se permite sincronizar».
4. No se puede evitar el robo de sesión. La passkey solo protege el instante del inicio de sesión; si la cookie de sesión posterior se roba mediante malware o XSS, el método de autenticación deja de importar. Sigue quedando el trabajo de otra capa: la vida útil del token, su vinculación (binding) y la gestión del estado de salud del dispositivo.

Nada de esto significa que haya que renunciar a las passkeys. Es simplemente la obviedad de que, aunque se cambie la cerradura de la puerta principal, cerrar bien las ventanas sigue siendo otra tarea distinta. Al contrario: al quedar clara la ubicación de las debilidades, se puede concentrar mejor el esfuerzo de defensa en el flujo de recuperación y en la gestión de sesiones.

7. Implementación práctica — la API WebAuthn y el entorno Windows

Por último, repasamos los puntos clave desde la perspectiva de quien va a implementarlas.

Añadir el inicio de sesión con passkey a un servicio web propio

En el lado del navegador, basta con dos funciones de la API WebAuthn. Para el registro se llama a navigator.credentials.create(), y para la autenticación, a navigator.credentials.get().

// Registro (lado del navegador)
const credential = await navigator.credentials.create({
  publicKey: {
    challenge: challengeFromServer,   // Número aleatorio de un solo uso generado por el servidor
    rp: { id: "example.com", name: "Example" },
    user: { id: userIdBytes, name: "juan@example.com", displayName: "Juan" },
    pubKeyCredParams: [{ type: "public-key", alg: -7 }],  // ES256
    authenticatorSelection: {
      residentKey: "required",        // Convertirla en credencial detectable (= passkey)
      userVerification: "required",   // Exigir verificación de identidad por biometría o PIN
    },
  },
});
// La clave pública se extrae de credential.response, y el credential ID de
// credential.id / credential.rawId en el nivel superior. La respuesta de
// registro también debe verificarse en el servidor (desafío, origen y RP ID)
// del mismo modo que en la autenticación, antes de guardarla

Los parámetros principales significan lo siguiente.

Tabla 4: parámetros principales de navigator.credentials.create()

Nota sobre el entorno de pruebas: como la API WebAuthn solo se expone en un contexto seguro, la llamada a navigator.credentials falla en una página servida por http:// sin más. La excepción es http://localhost (y 127.0.0.1), que se tratan como orígenes de confianza, así que en la máquina de desarrollo se puede probar directamente sin necesidad de pasar a HTTPS. Sin embargo, el RP ID debe ser el dominio efectivo del origen (o un dominio padre de este), así que una passkey creada en localhost no puede usarse en el dominio de producción. Aunque no tenga un autenticador físico a mano, si habilita el autenticador virtual en la pestaña «WebAuthn» de las herramientas de desarrollo de Chrome, puede probar todo el ciclo, desde el registro hasta la autenticación.

// Autenticación (lado del navegador)
const assertion = await navigator.credentials.get({
  publicKey: {
    challenge: challengeFromServer,
    rpId: "example.com",
    userVerification: "required",
  },
  // Ofrece la passkey como sugerencia de autocompletado en el campo de inicio
  // de sesión. Compruebe antes la compatibilidad con
  // PublicKeyCredential.isConditionalMediationAvailable() y, en navegadores
  // sin soporte, recurra a la llamada normal sin especificar mediation
  mediation: "conditional",
  // (el <input> correspondiente necesita autocomplete="username webauthn")
});
// La firma de assertion.response se verifica en el servidor

Lo esencial es la verificación en el servidor. Como mínimo, siempre hay que hacer lo siguiente.⁵

• Verificación del desafío: ¿es un desafío emitido por usted mismo y aún no usado? ¿Se trata como de un solo uso (medida contra la repetición)? Además, guárdelo vinculado a la sesión del navegador (el intento de inicio de sesión) en el momento de la emisión, y permita que se consuma solo con una respuesta procedente de la misma sesión. Si esto se relaja, se abre la posibilidad de un ataque en el que el atacante envía, a través del navegador de la víctima, la firma de un desafío dirigido a él mismo, haciendo que la víctima inicie sesión en la cuenta del atacante (CSRF de inicio de sesión).
• Verificación del origen: ¿el origin de clientDataJSON es el origen legítimo de su propio sitio? (el pilar de la protección contra el phishing).
• Verificación del hash del RP ID: ¿el rpIdHash de authenticatorData coincide con el SHA-256 del RP ID de su propio sitio?
• Confirmación del tipo de ceremonia y de las banderas: ¿el type de clientDataJSON es webauthn.get para autenticación o webauthn.create para registro? ¿Está activada la bandera UP (presencia del usuario) de authenticatorData? Si se exigió verificación de usuario (UV), ¿también está activada la bandera UV?
• Verificación de la firma: ¿la firma se verifica correctamente con la clave pública guardada durante el registro?
• Vinculación con la cuenta: ¿busca el credential ID presentado (y el userHandle) en su propia base de datos, y emite la sesión para el titular real de esa credencial? Confiar sin condiciones en un nombre de usuario introducido por separado abre un agujero que permite iniciar sesión como otra persona con una firma correcta.
• Almacenamiento y comparación del contador de firmas: guarde el signCount de authenticatorData por cada credencial, y confirme que el valor de la siguiente vez es mayor que el anterior. Si es igual o menor que el valor anterior (incluido el mismo valor), trátelo como indicio de una clonación del autenticador. No obstante, como muchas implementaciones de passkeys sincronizadas devuelven siempre 0, permita como única excepción el caso de 0 contra 0.

Escribir esta verificación a mano es fuente de errores, así que use una biblioteca acreditada (para .NET, fido2-net-lib; para Node.js, SimpleWebAuthn, entre otras). Delegue en la biblioteca los detalles del estándar (el análisis de CBOR, el acuerdo de algoritmos, la gestión de desafíos), y concentre sus propios esfuerzos en el almacenamiento y la caducidad de los desafíos, la interfaz de gestión de varias passkeys y el diseño del flujo de recuperación: esa es la distribución de esfuerzo correcta.

En el caso de entornos Windows y sistemas internos

Para el perfil de lector de este sitio —quien tiene a su cargo sistemas empresariales de Windows—, basta con tener presentes estos tres puntos.

• El cliente de Windows ya lo admite. Windows 11 es compatible con la creación, el uso y la gestión de passkeys (Configuración > Cuentas > Passkeys) usando Windows Hello como autenticador, y la clave privada queda protegida por hardware si hay un TPM disponible.¹⁰ El WebAuthn a través del navegador (Edge/Chrome) también funciona en Windows 10.
• En un entorno Entra ID, habilite el método de autenticación «passkey = FIDO2». Microsoft Entra ID admite llaves de seguridad y passkeys dentro de la aplicación Microsoft Authenticator (de tipo vinculado al dispositivo), y si exige «MFA resistente al phishing» en la solidez de autenticación del acceso condicional, puede limitar el acceso a los recursos objetivo a passkeys y similares.⁹ La migración desde el mundo de NTLM y las políticas de caducidad de contraseñas no avanza de un salto, así que lo recomendable es, en paralelo con el inventario de la infraestructura de autenticación que tratamos en el artículo sobre NTLM y Kerberos, empezar por hacer obligatorio el MFA resistente al phishing en las cuentas de administrador.
• El beneficio es el mismo para las aplicaciones web internas, pero se necesita HTTPS. Como la API WebAuthn solo funciona en un contexto seguro, para las aplicaciones de intranet también es prioritario (salvo en localhost durante el desarrollo) pasar a HTTPS y ordenar los nombres de dominio internos que puedan usarse como RP ID. Una vez resuelto eso, el RP ID funciona igualmente para dominios internos. En el sentido de romper con la nota adhesiva de contraseñas, no es raro que el efecto se note antes en el uso interno que en los servicios de cara al exterior.

8. Resumen

• La debilidad de la contraseña no está en su fortaleza, sino en la estructura de “compartir el secreto y enviarlo cada vez que se autentica”. Como el secreto existe en el usuario, en el campo de entrada, en la ruta y en el servidor, hay muchos objetivos de ataque. Aunque se añada un código de un solo uso, el phishing de tipo AiTM lo retransmite y lo vence igualmente.
• La passkey es un par de claves de criptografía de clave pública por cada sitio: al servidor solo se le entrega la clave pública, que no se puede explotar aunque se filtre, y al iniciar sesión solo se envía la firma de un desafío de un solo uso. No hay secreto en el servidor, y tampoco circula ningún secreto por la ruta.
• Como en la firma quedan incorporados el origen y el RP ID confirmados por el navegador, en un sitio falso la passkey del sitio genuino no aparece como opción, y aunque se retransmita, la verificación la rechaza. Que el usuario no necesite detectar el sitio falso es la verdadera naturaleza de la «resistencia al phishing»: el fundamento de la defensa pasó de la atención humana a la estructura del protocolo.
• La passkey sincronizada se sincroniza mediante cifrado de extremo a extremo y es resistente al cambio de equipo y a la pérdida. A cambio, el lugar que hay que proteger se concentra en la cuenta en la nube, por lo que proteger la propia cuenta de Apple ID o Google es una condición imprescindible. En el ámbito corporativo también se puede optar por el tipo vinculado al dispositivo (llave de seguridad, passkey de Authenticator en Entra ID).
• La passkey no elimina los ataques, sino que los empuja hacia los lugares débiles. La contraseña que coexiste, el flujo de recuperación de cuenta y el robo de sesión siguen siendo superficies de ataque, y el objetivo central de su implementación está en la reducción planificada del respaldo y en el fortalecimiento del flujo de recuperación.
• La implementación se reduce a las dos funciones create / get de la API WebAuthn, más la verificación en el servidor. No cree su propia verificación: delegue en una biblioteca acreditada, y dedique el esfuerzo a la gestión de desafíos, la interfaz de varias passkeys y el diseño de la recuperación.

Artículos relacionados

• Qué es el TPM de Windows — el «cofre que no deja salir la clave» y el arranque medido, explicados con diagramas
• NTLM y Kerberos explicados con diagramas — por qué la autenticación «cae» a NTLM
• Integrar la autenticación de Entra ID en aplicaciones WinForms/WPF — configuración práctica con MSAL.NET y el bróker WAM
• Manejo seguro de credenciales en PowerShell — cómo desterrar las contraseñas en texto plano de los scripts
• Lista de comprobación mínima de seguridad para el desarrollo de aplicaciones Windows
• Por dónde empezar la seguridad en la pyme — cómo recorrer la versión 4.0 de la «Guía de medidas de seguridad de la información para pymes» de la IPA

Áreas de consultoría relacionadas

KomuraSoft LLC ofrece desarrollo por encargo que incluye el apoyo en la implementación de WebAuthn para el inicio de sesión con passkey en sistemas web internos, el diseño del despliegue de MFA resistente al phishing en entornos Entra ID, y la incorporación de autenticación en aplicaciones empresariales de Windows como WinForms/WPF.

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.

¿Cuál es la diferencia fundamental entre una passkey y una contraseña?

Una contraseña es un mecanismo en el que el usuario y el servidor comparten el mismo secreto, y ese secreto se envía cada vez que se inicia sesión. Como el secreto existe en todas partes —en la mente del usuario, en el campo de entrada, en la ruta de comunicación y en la base de datos del servidor—, todos esos lugares se convierten en objetivos de ataque. Las passkeys utilizan un par de claves de criptografía de clave pública, y la clave privada nunca se envía al servidor. En el tipo vinculado al dispositivo, la clave privada nunca sale del autenticador; incluso en el tipo sincronizado, solo sale en forma cifrada de extremo a extremo. Lo único que se almacena en el servidor es la clave pública, una «información que no se puede explotar aunque se filtre», y lo único que se envía al iniciar sesión es una firma sobre un desafío de un solo uso. En otras palabras, el «secreto compartido» que era el punto débil de las contraseñas simplemente no existe. Además, como el par de claves se genera por separado para cada sitio, el concepto mismo de reutilización deja de tener sentido.

¿Se envían los datos biométricos (huella dactilar, rostro) al servidor?

No se envían. Los datos de huella dactilar o rostro se usan únicamente como verificación local dentro del dispositivo, para «abrir la puerta de la caja fuerte que contiene la clave privada», y por diseño de FIDO, la información biométrica nunca sale del dispositivo. Lo que recibe el servidor es solo una firma con el indicador de que se realizó la verificación de identidad del usuario (verificación de usuario); no incluye la huella en sí ni tampoco sus características extraídas. Cuando la biometría no está disponible, puede sustituirse por un PIN, pero al igual que el PIN de Windows Hello, este también se verifica exclusivamente en el dispositivo local, y el hecho de que no circule por la red es la diferencia decisiva respecto a una contraseña.

¿Por qué las passkeys son resistentes al phishing?

Porque, por el propio funcionamiento del mecanismo, el usuario nunca necesita detectar un sitio falso. Las passkeys se crean vinculadas al dominio del sitio (RP ID), y el navegador solo ofrece como candidatas las passkeys que corresponden al «dominio del sitio que se está mostrando en ese momento». Aunque se acceda a un dominio falso idéntico en apariencia al real, la passkey del sitio genuino simplemente no aparece entre las opciones, de modo que el usuario no tiene forma de ser engañado. Además, la firma incorpora el hash del origen y del RP ID verificados por el navegador, por lo que, aunque se llegara a retransmitir la firma, la verificación del servidor legítimo la rechazará. Que el accidente de «introducir credenciales reales en un sitio falso» sea estructuralmente imposible —a diferencia de lo que ocurre con contraseñas o códigos SMS— es la diferencia fundamental frente a las medidas que dependen de la capacitación o de la vigilancia del usuario.

Si pierdo el móvil, ¿me quedaré sin poder entrar a mi cuenta?

Si se trata de una passkey sincronizada (de las que se guardan en el llavero de iCloud o en el Administrador de contraseñas de Google), podrá restaurarla en un nuevo dispositivo con solo iniciar sesión en la misma cuenta de Apple ID o Google. Sin embargo, restaurar un almacén cifrado de extremo a extremo requiere, además de la contraseña de la cuenta, una verificación de identidad adicional —como introducir el código de bloqueo de pantalla del dispositivo anterior—, así que si también pierde esos medios de recuperación podría no poder restaurarla. Es importante no confiar todo a un único teléfono. Las passkeys vinculadas al dispositivo (llaves de seguridad, Windows Hello, etc.) comparten el destino del dispositivo, por lo que la práctica recomendada para las cuentas importantes es registrar varias passkeys. La mayoría de los servicios permiten registrar varias passkeys por cuenta. Tenga en cuenta que el procedimiento de invalidación en caso de pérdida cambia según el tipo. En el tipo sincronizado, la copia de cada dispositivo es la misma credencial única, así que lo primero es eliminar el dispositivo perdido o realizar un borrado remoto desde la cuenta de la plataforma para inutilizar la copia que quedó en el dispositivo (si elimina esa passkey desde la configuración de la cuenta del servicio, las copias de todos los dispositivos se invalidan de una sola vez). En el tipo vinculado al dispositivo, basta con que el servicio elimine la passkey de ese autenticador para invalidar únicamente la clave perdida. En un entorno corporativo, es fundamental diseñar en conjunto tanto la «redundancia que permite al usuario recuperarse por sí mismo» como el «procedimiento con el que el administrador revoca el acceso en caso de pérdida».

¿Las passkeys también tienen puntos débiles?

Sí los tienen. Aunque es más preciso decir que el lugar donde está la debilidad cambia. Como la autenticación en sí se vuelve más fuerte gracias a la criptografía de clave pública, los atacantes apuntan a la periferia, más débil. En concreto: si siguen coexistiendo medios tradicionales como la contraseña o el SMS, ese sigue siendo el eslabón más débil; existe la táctica de abusar del flujo de recuperación de cuenta para que el atacante registre su propia passkey; y en el tipo sincronizado, la toma de control de la propia cuenta en la nube se convierte en un nuevo punto único de fallo. Además, los ataques que roban la cookie de sesión después del inicio de sesión no se detienen con passkeys, así que tampoco desaparecen las amenazas que no tienen relación con esto. Al implementarlas, no basta con «añadir passkeys»: hay que diseñar también el fortalecimiento del flujo de recuperación y la reducción planificada de los medios de respaldo.

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.