# Passkeys, autenticación sin contraseña y Zero Trust

**Categoría:** Hacking ético · **Nivel:** Intermedio · **Lectura:** 13 min
**Publicada:** 2026-07-27 · **Actualizada:** 2026-07-27 · **Autoría:** Underc0de
**Versión HTML (canónica):** https://underc0de.org/guias/hacking/passkeys-autenticacion-sin-contrasena-y-zero-trust/

## Respuesta rápida

Una **passkey** es, según la FIDO Alliance, «una credencial de autenticación FIDO basada en estándares FIDO, que permite iniciar sesión en aplicaciones y sitios con el mismo proceso que se usa para desbloquear el dispositivo». Funciona con **criptografía de clave pública**: la clave privada **nunca sale del dispositivo** y solo se usa para firmar un desafío. Eso elimina el **secreto compartido**, y con él la categoría entera de ataques que dependen de robarlo: phishing, reutilización de contraseñas, relleno de credenciales y filtraciones de bases. En paralelo, el **NIST SP 800-207** define la **confianza cero** como el conjunto de paradigmas que «mueven las defensas de los perímetros estáticos basados en la red hacia los usuarios, los activos y los recursos». Las dos ideas atacan el mismo supuesto: que haya algo confiable por su ubicación.

## El problema de fondo

Una contraseña es un **secreto compartido**: la persona lo sabe y el servidor guarda algo derivado de él. Todo el problema de la autenticación por contraseña sale de esa única propiedad, porque un secreto compartido se puede **robar, adivinar, reutilizar y entregar por error**.

De ahí salen los ataques clásicos, y vale verlos juntos para notar que son variaciones de lo mismo:

| Ataque | Cómo aprovecha el secreto |
|---|---|
| **Phishing** | Convence a la persona de escribirlo en el sitio del atacante |
| **Relleno de credenciales** | Prueba en tu sitio las contraseñas filtradas de otro |
| **Fuerza bruta** | Prueba hasta acertar |
| **Filtración de la base** | Se lleva los secretos de todos de una vez |
| **Intermediario** | Lo captura en tránsito, o replica el sitio y lo reenvía |

El segundo factor por mensaje de texto o por código temporal mitiga algunos y **no el phishing**: un sitio replicado pide el código igual y lo reenvía en el momento. Por eso el cambio de fondo no es agregar factores sino **eliminar el secreto**.

## Qué son las passkeys

La FIDO Alliance las define como «una credencial de autenticación FIDO basada en estándares FIDO, que permite iniciar sesión en aplicaciones y sitios con **el mismo proceso que se usa para desbloquear el dispositivo**». Esa última parte explica la adopción: para la persona, iniciar sesión es poner el dedo o mirar la cámara.

Por debajo hay dos momentos:

1. **Registro** El dispositivo genera un **par de claves**. Guarda la privada y le entrega al servicio solo la **pública**.
2. **Inicio de sesión** El servicio manda un **desafío**; el dispositivo lo firma con la clave privada —después de que la persona se autentique localmente— y el servicio verifica la firma con la pública.

Las tres consecuencias que importan: la **clave privada nunca viaja**, el servicio **nunca almacena un secreto reutilizable** —una filtración de su base entrega claves públicas, que son públicas— y **no hay nada que la persona pueda entregar por error**.

Del lado del navegador, la especificación es **WebAuthn** del W3C, hoy en *Candidate Recommendation Snapshot* del **26 de mayo de 2026** en su nivel 3. Define tres roles: la **parte confiante** —el servicio, que guarda la clave pública y verifica—, el **autenticador** —la entidad criptográfica que crea y guarda la credencial— y el **cliente**, que media entre los dos.

## Por qué resisten el phishing

Acá está la propiedad decisiva, y no es la criptografía: es el **vínculo con el dominio**.

Cuando se registra una passkey, la credencial queda **ligada al origen** del sitio. Al momento de iniciar sesión, el navegador solo ofrece las credenciales registradas **para ese dominio exacto**. Un sitio replicado en otro dominio —por parecido que sea el nombre— **no recibe nada**: no es que la persona deba notar la diferencia, es que la credencial no está disponible ahí.

> **La diferencia con una advertencia**
>
> Todas las defensas anteriores contra el phishing dependían de que **alguien se diera cuenta**: mirar la barra de direcciones, notar un dominio raro, dudar de un correo. Y la gente, con prisa y bajo presión, no se da cuenta —el blog de Underc0de documentó [ClickFix, una táctica de ingeniería social más efectiva que el malware](https://blog.underc0de.org/clickfix-la-tactica-de-ingenieria-social-que-supero-al-malware/)—. Con passkeys, la protección **no depende de la atención de nadie**. Es lo que en seguridad se busca siempre y casi nunca se consigue.

Y algo que suele confundirse: la verificación local —huella, rostro, PIN— **no viaja a ningún lado**. Sirve para desbloquear el uso de la clave en el dispositivo. El servicio nunca recibe tu huella; recibe una firma.

## Sincronizadas o ligadas al dispositivo

La distinción que más consecuencias tiene al implementar, y que casi nunca se explica:

|  | Sincronizadas | Ligadas al dispositivo |
|---|---|---|
| Dónde vive la clave | Se comparte entre los dispositivos de la persona por un proveedor, con cifrado de extremo a extremo | **Nunca sale** del dispositivo |
| Si se pierde el dispositivo | Se recupera desde otro | Se pierde la credencial |
| Qué prioriza | La **recuperación** y la comodidad | La **contención** de la clave |
| Dónde se usa | Uso general de consumo | Entornos regulados que lo exigen |
| Qué hay que confiar | Al proveedor de sincronización | Solo al dispositivo |

La elección no es técnica sino de **modelo de amenaza**. Para un servicio de consumo, las sincronizadas son claramente mejores: si perder el teléfono significa perder la cuenta, la gente no adopta. Para un entorno donde la contención de claves es un requisito, las ligadas al dispositivo son la respuesta, a costa de un proceso de recuperación más caro.

## Qué sigue siendo atacable

La parte que suele faltar en la promoción del tema, y la más útil para quien evalúa. Las passkeys cierran una clase de ataques; **no cierran el sistema**.

| Sigue atacable | Por qué |
|---|---|
| **La recuperación de cuenta** | Si «perdí mi dispositivo» lleva a un correo o a un mensaje de texto, **ahí está el eslabón débil** y vuelve a ser un secreto |
| **El método alternativo** | Si se conserva la contraseña «por si acaso», el atacante usa ese camino |
| **La sesión ya iniciada** | Robar la cookie de sesión saltea la autenticación por completo |
| El registro de la credencial | Si alguien registra una passkey en una cuenta ajena, tiene acceso permanente |
| La autorización | Autenticarse bien no arregla un [control de acceso roto](../owasp-top-10-2025-explicado/index.md) |
| El dispositivo | Comprometido el dispositivo, la clave se usa desde ahí |

Las dos primeras son las que más se ven en la práctica, y las dos tienen la misma forma: **el sistema es tan fuerte como su camino más débil**. Implementar passkeys y dejar la contraseña activa como respaldo no mejora la seguridad; mejora la comodidad y deja la superficie intacta.

## Zero Trust, según el NIST

El término está tan usado por el marketing que conviene ir a la definición formal. El **NIST SP 800-207**, «*Zero Trust Architecture*», de **agosto de 2020**, la establece así:

> **Atención**
>
> «**Confianza cero** es el término para un conjunto en evolución de paradigmas de ciberseguridad que **mueven las defensas de los perímetros estáticos basados en la red** hacia los usuarios, los activos y los recursos.»
>
> «Una **arquitectura de confianza cero** usa principios de confianza cero para planificar la infraestructura y los flujos de trabajo industriales y empresariales.»
>
> Y el supuesto central: «**no se otorga confianza implícita** a activos o cuentas de usuario basándose únicamente en su ubicación física o de red —redes locales frente a internet— o en la propiedad del activo».

Traducido a consecuencias prácticas: **estar dentro de la red deja de ser una credencial**. Cada petición se autentica y autoriza por sí misma, sin importar de dónde venga. El documento señala además que la autenticación y la autorización de **usuario y dispositivo** se hacen **por separado** antes de conceder acceso a un recurso, y que la protección se centra en los **recursos** y no en segmentos de red.

Lo que motivó el cambio también está explicado: trabajo remoto, dispositivos propios y recursos en la nube fuera del perímetro tradicional. El perímetro no se debilitó: **dejó de existir como frontera útil**.

## Cómo se relacionan

Passkeys y confianza cero se nombran juntas y casi nunca se explica por qué. La relación es directa y vale enunciarla:

La confianza cero exige verificar **en cada petición** quién pide y con qué dispositivo. Eso sube muchísimo la cantidad de verificaciones, y con contraseñas ese modelo es insostenible: nadie escribe una contraseña veinte veces por día, y si se le pide, elige una mala o la anota.

Las passkeys hacen viable ese modelo porque **la verificación es barata para la persona** —un gesto— y **fuerte para el sistema**. Sin autenticación sin fricción, la confianza cero se degrada en la práctica hasta volver a confiar en la red.

Dicho en una línea: **las passkeys responden «quién sos» con una prueba que no se puede transferir; la confianza cero deja de usar la ubicación para responder «qué podés hacer»**. Son la misma idea aplicada a las dos preguntas.

## Qué revisar en una evaluación

Sobre sistemas propios o con autorización escrita, como todo en esta categoría. Las preguntas que más encuentran:

- **¿Qué pasa con «perdí mi dispositivo»?** Es la pregunta número uno. Si termina en un código por mensaje de texto, ahí está la vulnerabilidad real.
- **¿Quedó la contraseña activa como alternativa?** Si sí, la mejora es de comodidad y no de seguridad.
- **¿Se puede registrar una credencial nueva sin reautenticar con la existente?** Es la vía para hacerse persistente en una cuenta ajena.
- **¿Cuánto dura la sesión y se puede revocar?** Una sesión eterna anula el modelo.
- **¿Se verifica el dispositivo, además del usuario?** El NIST lo pide por separado.
- **¿La autorización se comprueba en cada petición o solo al entrar?** Es la diferencia entre confianza cero y su etiqueta.
- **¿Hay registro de los eventos de autenticación y de registro de credenciales?** Sin eso no se puede investigar nada.

> Estas comprobaciones se hacen dentro de un marco autorizado; el encuadre está en [fundamentos de hacking ético](../fundamentos-hacking-etico/index.md). Y la categoría de OWASP que cubre este terreno es **A07, fallas de autenticación**, tratada en [OWASP Top 10 2025 explicado](../owasp-top-10-2025-explicado/index.md).

## Errores frecuentes

- **Dejar la contraseña como método alternativo.** El atacante usa el camino más débil.
- **Recuperación por mensaje de texto o correo.** Reintroduce el secreto compartido que se quiso eliminar.
- **Creer que la huella viaja al servidor.** La verificación es local; lo que viaja es una firma.
- **Ignorar la diferencia entre sincronizadas y ligadas al dispositivo.** Es una decisión de modelo de amenaza, no de gusto.
- **Suponer que resuelven la autorización.** Autenticarse bien no arregla un control de acceso roto.
- **Llamar Zero Trust a comprar un producto.** Es una arquitectura, no una herramienta.
- **Verificar solo al iniciar sesión.** La confianza cero verifica en cada petición.
- **Olvidar el registro de credenciales nuevas.** Es la vía de persistencia más silenciosa.

## Preguntas frecuentes

**¿Qué es exactamente una passkey?**
Según la FIDO Alliance, una credencial de autenticación basada en estándares FIDO que permite iniciar sesión en aplicaciones y sitios con el mismo proceso que se usa para desbloquear el dispositivo. Por debajo funciona con criptografía de clave pública: al registrarse, el dispositivo genera un par de claves, guarda la privada y le entrega al servicio solo la pública. Al iniciar sesión, el servicio manda un desafío y el dispositivo lo firma. La clave privada nunca viaja y el servicio nunca almacena un secreto reutilizable.

**¿Por qué las passkeys resisten el phishing?**
Porque la credencial queda ligada al dominio del sitio donde se registró, y el navegador solo ofrece las credenciales de ese dominio exacto. Un sitio replicado en otro dominio no recibe nada, por parecido que sea el nombre. La diferencia con las defensas anteriores es enorme: todas dependían de que alguien se diera cuenta de algo —mirar la barra de direcciones, dudar de un correo—, y acá la protección no depende de la atención de nadie. Es una propiedad del protocolo, no una advertencia que se pueda ignorar.

**¿Mi huella digital se envía al servidor?**
No. La verificación biométrica —huella, rostro— o el PIN sirven para desbloquear el uso de la clave privada en el propio dispositivo, y esa información no sale de ahí. Lo que el servicio recibe es una firma criptográfica del desafío que él mismo mandó, más la confirmación de que hubo verificación del usuario. Es una distinción importante porque despeja la preocupación más común sobre las passkeys: no hay una base de datos de huellas del otro lado.

**¿Qué diferencia hay entre passkeys sincronizadas y ligadas al dispositivo?**
Las sincronizadas se comparten entre los dispositivos de la persona a través de un proveedor, con cifrado de extremo a extremo, así que si se pierde un dispositivo la credencial se recupera desde otro. Las ligadas al dispositivo nunca salen de él, lo que da contención estricta de la clave a costa de que perder el dispositivo signifique perder la credencial. La elección es de modelo de amenaza: para servicios de consumo las sincronizadas favorecen la adopción; para entornos regulados que exigen contención, las ligadas.

**¿Las passkeys hacen segura una aplicación?**
Cierran una clase de ataques, no el sistema. Sigue siendo atacable la recuperación de cuenta, y es el eslabón que más se explota: si «perdí mi dispositivo» termina en un código por mensaje de texto, el secreto compartido volvió por la ventana. También sigue en pie el método alternativo si se conservó la contraseña, el robo de la sesión ya iniciada, el registro de una credencial nueva en una cuenta ajena, y cualquier falla de autorización, porque autenticarse bien no arregla un control de acceso roto.

**¿Qué es Zero Trust según el NIST?**
El NIST SP 800-207, de agosto de 2020, la define como el término para un conjunto en evolución de paradigmas de ciberseguridad que mueven las defensas de los perímetros estáticos basados en la red hacia los usuarios, los activos y los recursos. Su supuesto central es que no se otorga confianza implícita a un activo o a una cuenta solo por su ubicación física o de red, ni por quién es su dueño. En la práctica significa que estar dentro de la red deja de ser una credencial y que cada petición se autentica y autoriza por sí misma.

## Fuentes

Documentación oficial y material de la comunidad consultados para esta guía. Fecha de consulta: 27 de julio de 2026.

### Aportes de la comunidad Underc0de

1. **Underc0de, blog.** [ClickFix: la táctica de ingeniería social que superó al malware](https://blog.underc0de.org/clickfix-la-tactica-de-ingenieria-social-que-supero-al-malware/), 6 de agosto de 2025. Por qué el factor humano sigue siendo el vector principal.
2. **Underc0de, foro.** [Sección Seguridad web y en servidores](https://underc0de.org/foro/seguridad-en-servidores/). Configuración de autenticación y control de accesos.

### Documentación oficial

1. **FIDO Alliance.** [Passkeys](https://fidoalliance.org/passkeys/). La definición de passkey, el funcionamiento con criptografía de clave pública y la distinción entre sincronizadas y ligadas al dispositivo, citadas en esta guía.
2. **W3C.** [Web Authentication: An API for accessing Public Key Credentials — Level 3](https://www.w3.org/TR/webauthn-3/). Candidate Recommendation Snapshot del 26 de mayo de 2026. La especificación del navegador y los tres roles.
3. **NIST.** [SP 800-207: Zero Trust Architecture](https://csrc.nist.gov/pubs/sp/800/207/final), agosto de 2020. Las definiciones de confianza cero y de arquitectura de confianza cero, citadas textualmente.
4. **NIST.** [SP 800-63: Digital Identity Guidelines](https://pages.nist.gov/800-63-4/). Los niveles de garantía de autenticación.
5. **OWASP.** [Authentication Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html). Prácticas de implementación de autenticación.

## Guías relacionadas

- [OWASP Top 10 2025](../owasp-top-10-2025-explicado/index.md)
- [Fundamentos de hacking ético](../fundamentos-hacking-etico/index.md)
- [SSL y HTTPS](../../desarrollo-web/ssl-tls-certificados-y-https/index.md)
- [Seguridad de agentes](../../inteligencia-artificial/seguridad-de-agentes-y-aplicaciones-de-ia/index.md)
- [Índice de Hacking ético](../index.md)