Las passkeys no son una trampa

Las passkeys —inicios de sesión sin contraseña basados en criptografía de clave pública— se promocionan como una alternativa más segura y resistente al phishing frente a las contraseñas y los códigos TOTP, pero su impacto en el mundo real sigue siendo objeto de controversia. Los comentaristas sopesan las ventajas de seguridad y comodidad (especialmente cuando se sincronizan mediante grandes ecosistemas o gestores de contraseñas) frente a serias preocupaciones sobre el bloqueo de proveedor, el uso de la atestación para excluir soluciones abiertas o autohospedadas, una UX confusa en múltiples dispositivos y los modos de fallo en la recuperación de cuentas. Muchos concluyen que las passkeys son prometedoras en entornos corporativos estrechamente gestionados o de un solo proveedor, pero arriesgadas o prematuras como reemplazo universal de las contraseñas y la 2FA tradicional.

Alcance del debate

  • La mayoría de los comentaristas acepta que las passkeys son, técnicamente, una autenticación de clave pública sólida, pero discute si el ecosistema y los estándares actuales son fáciles de usar o seguros frente al abuso.
  • El hilo se centra sobre todo en: la atestación y el riesgo de bloqueo de proveedor, la portabilidad, los fallos de UX y los distintos modelos de amenaza frente a contraseñas+TOTP.

Atestación, bloqueo de proveedor y preocupaciones de “trampa”

  • La atestación de WebAuthn permite a los sitios conocer el modelo del autenticador (AAGUID) y potencialmente restringir qué autenticadores están permitidos.
  • Los críticos argumentan que este es un “dial” que puede girarse más adelante: empezar con ajustes permisivos y luego exigir gradualmente autenticadores atestados y aprobados por el proveedor.
  • Ejemplos concretos citados:
    • Configuraciones corporativas de Microsoft Entra que solo permiten Microsoft Authenticator.
    • Sistemas de e‑ID suizo y austriaco que ponen en lista blanca unos pocos tokens de hardware.
    • Un participante de FIDO amenazando con que el comportamiento no conforme de KeepassXC podría llevar a que fuera bloqueado por las partes que confían en él.
  • Los defensores responden: las plataformas de consumo más extendidas actualmente devuelven none y los grandes sitios no arriesgarían bloquear a los usuarios de inmediato; algunos grandes proveedores desaconsejan públicamente la atestación para sitios de consumo.
  • Los escépticos replican que “todavía no se usa” no elimina la capacidad, y que los estándares pueden evolucionar bajo presión comercial o regulatoria.

Portabilidad, bloqueo de ecosistema y copias de seguridad

  • La experiencia es muy inconsistente entre Apple, Google, Microsoft, navegadores y gestores de contraseñas.
  • Algunos reportan migraciones fluidas (por ejemplo, Apple ↔ 1Password/Bitwarden, especificaciones CXF/CXP), otros encuentran:
    • Sin exportación genérica, solo transferencias de app a app hacia una lista cerrada de aplicaciones permitidas.
    • Hardware/software explícitamente rechazado (por ejemplo, Bitwarden, KeePassXC, Linux+Firefox).
  • Muchos temen depender de una sola cuenta en la nube (iCloud/Google) y escenarios de bloqueo por parte del proveedor; valoran poder imprimir o archivar por su cuenta contraseñas/secretos TOTP.

Beneficios de seguridad frente a contraseñas/TOTP

  • Argumentos a favor de las passkeys:
    • Fuerte resistencia al phishing: las claves están vinculadas a dominios y no pueden reutilizarse ni filtrarse como contraseñas o códigos TOTP.
    • Las filtraciones del servidor exponen solo claves públicas; no hay cracking de contraseñas.
    • Para usuarios no técnicos que reutilizan contraseñas y caen en phishing, esto supone una gran mejora en el mundo real.
  • Puntos de vista escépticos:
    • Buenos gestores de contraseñas con contraseñas únicas y TOTP ya mitigan la mayor parte del riesgo; para esos usuarios, el beneficio adicional es marginal.
    • Existen ataques a los ecosistemas de passkeys (phishing de restablecimiento/inscripción de contraseña, implementaciones con errores, compromiso del dispositivo, problemas tipo “pass-the-key”).
    • Los flujos de recuperación y los factores secundarios (correo/SMS, códigos de respaldo) siguen siendo vulnerables al phishing, así que no se elimina el phishing, solo se desplaza.

Usabilidad, recuperación y modelos de amenaza

  • Muchos describen las passkeys como un “lío confuso”:
    • Múltiples “gestores” competidores por dispositivo; no está claro dónde se almacena una credencial.
    • Compatibilidad rota o incompleta en Linux, VMs, escritorios remotos o máquinas sin Bluetooth.
    • Sitios que gestionan mal varias passkeys, mezclan passkey con la contraseña+2FA existente de formas extrañas o fuerzan el alta mediante patrones oscuros.
  • Pérdida y recuperación:
    • La gente teme perder todos los dispositivos, bloqueos de cuenta del proveedor o cambios entre plataformas (iOS→Android, cuentas corporativas frente a personales).
    • Los flujos solo con hardware o atestados generan miedo a un bloqueo irreversible, frente a la capacidad actual de conservar copias en papel y almacenes de contraseñas fáciles de migrar.
  • Los modelos de amenaza difieren:
    • Algunos priorizan el phishing y los ataques masivos → favorecen las passkeys.
    • Otros priorizan el control, el anonimato y la resiliencia frente al abuso del proveedor o la coerción estatal → favorecen contraseñas+TOTP y claves autogestionadas.

División entre empresa y consumidor

  • En entornos corporativos, muchos informan de despliegues exitosos de Yubikey/passkeys con una recuperación central fuerte, y a los usuarios les alegra abandonar las contraseñas.
  • La principal preocupación es que estos controles de estilo empresarial (atestación, listas blancas, apps propietarias obligatorias) se apliquen a banca de consumo, administración pública y servicios “de uso obligado”.

Sentimiento general

  • Entusiastas: las passkeys son una mejora clara, especialmente con un buen gestor de contraseñas multiplataforma; los temores sobre la atestación están exagerados.
  • Escépticos: las passkeys incorporan nuevo poder para plataformas y partes que confían en ellas, la UX es frágil, la portabilidad está restringida y el riesgo de “girar el dial” en el futuro las convierte en una posible trampa a largo plazo.