Passkeys o contraseñas: el riesgo cambia al proveedor que las sincroniza

|Autor: Equipo editorial de QUASA|7 lectura mínima| 1
Passkeys o contraseñas: el riesgo cambia al proveedor que las sincroniza

Las passkeys resisten mejor el phishing que las contraseñas: cada credencial corresponde a un servicio y no hay una contraseña que introducir en una página falsa, como explica la guía del NIST sobre contraseñas y passkeys. Esa ventaja se mantiene tanto en las credenciales sincronizadas como en las ligadas a un dispositivo. En esta comparación, la diferencia decisiva aparece cuando hay que conservar o recuperar el acceso.

Una passkey sincronizada puede seguir disponible tras perder un teléfono, siempre que el usuario conserve otro dispositivo autorizado o recupere su cuenta con el proveedor. Esa comodidad concentra parte de la seguridad en quien guarda y restaura las copias: la evaluación de Büttner y Gruschka sitúa en el proveedor gran parte de la protección de estas credenciales. Una credencial ligada a un solo dispositivo evita esa ruta de sincronización, pero obliga a preparar otra forma de entrar si el dispositivo desaparece.

La ventaja frente a una página falsa

Una contraseña es un secreto que el usuario puede escribir o pegar donde se le solicite. Si lo hace en una copia convincente del sitio legítimo, el atacante puede recibirla. Usar una contraseña distinta para cada cuenta limita el daño de una filtración en otro servicio, y añadir un segundo factor dificulta el acceso indebido. Sin embargo, los códigos que el usuario introduce durante el inicio de sesión pueden capturarse en un ataque que intermedia esa sesión.

Con FIDO2, el servicio guarda una clave pública y el dispositivo autorizado responde a un desafío mediante una operación con la clave privada. La respuesta queda vinculada al dominio legítimo, por lo que una página impostora no obtiene una credencial reutilizable para ese servicio. En una passkey sincronizada, el proveedor puede distribuir copias protegidas de la clave privada a dispositivos autorizados; en una credencial ligada al dispositivo, esa clave no se exporta. El mecanismo de acceso protege frente al phishing en ambos casos, aunque el lugar donde se guardan las copias cambia las posibilidades de ataque y recuperación.

Cuatro situaciones que cambian la elección

El análisis del NCSC sobre credenciales personales compara estos métodos a lo largo de su uso, sincronización y recuperación. Conviene distinguir lo que ocurre en el inicio de sesión de lo que puede suceder después con el dispositivo o la cuenta que administra las credenciales.

  • Una página de acceso falsa. Una contraseña introducida allí queda expuesta; un código solicitado a continuación también puede ser interceptado. Una passkey, sincronizada o ligada al dispositivo, responde para el servicio legítimo. Esa protección del inicio de sesión no convierte en seguro un método alternativo más débil que la misma cuenta todavía acepte.
  • Robo de un dispositivo. Si otra persona conoce el PIN o dispone de un equipo ya desbloqueado, puede intentar usar las credenciales accesibles en él. El resultado depende de la protección del dispositivo y del gestor, además de la verificación exigida para usar cada credencial. Perder una llave de seguridad protegida por PIN presenta condiciones distintas a perder un teléfono abierto con sesiones activas; la sincronización no resuelve por sí sola ninguno de esos accesos locales.
  • Pérdida del único dispositivo. Una passkey sincronizada puede restaurarse en otro equipo mediante la cuenta del proveedor, si el usuario supera su proceso de recuperación. Una credencial no exportable se pierde con el teléfono o la llave que la contiene: para evitar recuperar cada servicio por separado, hace falta haber registrado otra credencial. Una contraseña recordada puede sobrevivir a la pérdida del aparato, pero el segundo factor o el gestor donde estaba guardada quizá dependan de él.
  • Compromiso de la cuenta de sincronización. Si un atacante consigue autorizar un dispositivo nuevo y superar los controles de restauración, puede intentar obtener acceso a las passkeys sincronizadas. Conocer solo la contraseña del proveedor no implica automáticamente poder usarlas: importa qué verificaciones adicionales exige para incorporar equipos y recuperar las claves. Las credenciales ligadas a un dispositivo carecen de esta ruta remota de copia.

El proveedor controla una parte de la seguridad

Sincronizar passkeys significa confiar al proveedor la custodia de copias cifradas y las reglas para entregarlas a los dispositivos de una cuenta. No todos aplican los mismos controles de acceso, incorporación de equipos y recuperación. Además, la cuenta del proveedor puede proteger también contraseñas o códigos guardados en un gestor sincronizado: esta dependencia no es exclusiva de las passkeys.

Las directrices del NIST para autenticadores sincronizables exigen que las claves copiadas se almacenen cifradas, que su acceso esté controlado y que el usuario emplee autenticación multifactor equivalente a AAL2 para acceder a ellas. Son requisitos para las implementaciones comprendidas en esas directrices, no una garantía de que cualquier proveedor comercial los cumpla. Al elegir uno, interesa saber cómo protege su cuenta, cómo autoriza un dispositivo nuevo y qué pruebas exige cuando el titular ha perdido todos los anteriores.

También cuenta la recuperación del servicio final. Si una cuenta permite volver a entrar mediante una contraseña, correo o SMS, esa vía puede ser el objetivo del atacante aunque el acceso habitual use una passkey. Retirar métodos alternativos puede reducir esa exposición, pero solo cuando queda una forma de respaldo que el titular realmente podrá utilizar. El equilibrio depende tanto de la cuenta que almacena las claves como de las opciones que conserva cada servicio.

Qué ocurre al cambiar de plataforma

La sincronización suele funcionar dentro de los dispositivos autorizados por un mismo proveedor. Si el usuario cambia de ecosistema, no debe dar por hecho que sus credenciales aparecerán en el equipo nuevo. La orientación de FIDO Alliance describe varias posibilidades: configurar un gestor compatible con ambas plataformas, usar el dispositivo antiguo para entrar y registrar otra passkey, o recurrir a la recuperación del servicio.

Una llave de seguridad FIDO2 ofrece otra forma de portabilidad: el usuario lleva el mismo objeto a un dispositivo compatible sin sincronizar su credencial. El acceso depende entonces de conservar la llave y de que el servicio permita usarla. Si se pierde la única llave registrada, cambiar de teléfono no devuelve la clave privada que estaba en ella.

Una decisión distinta para cada tipo de cuenta

Para una cuenta personal corriente, una passkey sincronizada ofrece una combinación útil de resistencia al phishing y recuperación tras perder un aparato. La elección incluye proteger la cuenta del proveedor con un método resistente al phishing y conocer su recuperación antes de depender de ella. Si el servicio todavía exige contraseña, conviene usar una única para esa cuenta y añadir autenticación multifactor.

Quien administra accesos de otras personas necesita mirar también las opciones del servicio: registro de varias credenciales, retirada de una credencial perdida, cierre de sesiones y control de métodos alternativos. En cuentas con privilegios elevados, una llave de seguridad con credencial ligada al dispositivo reduce la dependencia de la sincronización. Ese beneficio requiere una segunda llave registrada o una recuperación protegida, además de un procedimiento para revocar la llave extraviada.

Para el correo principal, la administración de sistemas o una cuenta financiera, la decisión debe cubrir tres preguntas concretas: quién puede usar un dispositivo perdido, quién puede restaurar las credenciales y qué vía alternativa permite recuperar la cuenta. Las respuestas varían entre proveedores y servicios. Elegir la opción más resistente al phishing es solo una parte de proteger el acceso que habrá que conservar a largo plazo.

Lee también:

Compartir:

Suscríbete a nuestro boletín

Reciba las últimas noticias sobre Web3, IA y criptomonedas directamente en su bandeja de entrada.

0