Las passkeys son una trampa

Artículo original ↗ Discusión en Hacker News ↗

Las passkeys —credenciales de inicio de sesión basadas en criptografía de clave pública y a menudo sincronizadas por Apple, Google o gestores de contraseñas— son elogiadas por ser mucho más resistentes al phishing que las contraseñas y los códigos TOTP, y por mejorar drásticamente la experiencia diaria de inicio de sesión. Sin embargo, los críticos sostienen que los estándares subyacentes WebAuthn/FIDO permiten passkeys “atestadas” vinculadas a hardware y pilas de SO específicas, que los sitios podrían llegar a exigir, encerrando a los usuarios en plataformas grandes y excluyendo dispositivos FOSS o no aprobados. Muchos ven las passkeys cómodas y copiables de hoy como un posible caballo de Troya: seguras y útiles ahora, pero con un riesgo real de control futuro por parte del proveedor y de menor libertad del usuario si la attestation llega a imponerse ampliamente.

Beneficios percibidos de las passkeys

  • Fuerte apoyo a las passkeys como resistentes al phishing: las claves están vinculadas al dominio, nunca se transmiten y las bases de datos robadas del servidor solo filtran claves públicas.
  • Muchos las ven como una mejora drástica de la UX frente a contraseñas+TOTP/SMS: “un clic y dentro”, sin teclear códigos, sin reglas de complejidad de contraseñas ni reutilización de contraseñas.
  • Quienes las defienden señalan que, en esencia, son autenticación de clave pública al estilo SSH envuelta en UX de navegador/SO, resolviendo problemas que los usuarios nunca gestionarían manualmente.
  • Los tokens de hardware (claves FIDO/U2F, Yubikeys) y las passkeys respaldadas por gestores de contraseñas son elogiados por ofrecer seguridad fuerte junto con cierto control del usuario.

Preocupaciones principales: attestation, control y el marco de “trampa”

  • La preocupación central: las especificaciones de WebAuthn/Passkey admiten attestation remota, lo que permite que los sitios exijan credenciales respaldadas por hardware, no exportables y aprobadas por la plataforma.
  • Temor a que, una vez que las passkeys se adopten ampliamente, los grandes sitios (especialmente bancos, streaming y redes sociales) “cambien el interruptor” y:
    • Rechacen passkeys sin attestation o gestionadas por software (Bitwarden, KeePassXC, etc.).
    • Bloqueen dispositivos FOSS, ROMs personalizadas, teléfonos rooteados o con el bootloader desbloqueado, y sistemas operativos no estándar.
  • Varios ven esto como parte de la tendencia más amplia de “trusted computing / secure boot / DRM / device attestation” que reduce el control del usuario.
  • Otros argumentan que esto está exagerado: la attestation es tecnología empresarial heredada, torpe de operar a escala de consumo y, por ahora, no se usa ni siquiera está soportada por algunas plataformas grandes.

Comparaciones de seguridad: TOTP, SMS, contraseñas, claves de hardware

  • TOTP:
    • Pro: controlado por el usuario, portátil, funciona con cualquier cliente, fácil de respaldar.
    • Con: fundamentalmente susceptible al phishing; los secretos compartidos en los servidores pueden ser exfiltrados; aún depende de contraseñas.
  • SMS y el OTP por correo electrónico se consideran ampliamente débiles: intercambio de SIM, interceptación, ingeniería social y una falsa sensación de seguridad.
  • Algunos sostienen que “TOTP es suficiente” y que las passkeys solo añaden complejidad y riesgo de políticas; otros lo llaman “el ‘solo usa contraseñas mejores’ de esta década”.

Usabilidad, portabilidad y temores de lock‑in

  • Muchas quejas sobre una UX fragmentada: el flujo de cada sitio (primero nombre de usuario vs. primero passkey, códigos de correo extra, etc.) difiere y puede ser confuso.
  • A la gente no le gusta verse obligada a usar almacenes de passkeys de la plataforma (Apple/Google/Windows) y no poder elegir dónde vive una passkey ni exportarla fácilmente.
  • Preocupaciones por perder el acceso si se pierde el teléfono o si una cuenta con un gran proveedor queda bloqueada o vetada.
  • Los usuarios avanzados quieren:
    • Múltiples autenticadores independientes por cuenta.
    • Copias de seguridad fuera de línea (incluidas copias en “metal safe”).
    • Compatibilidad continua con contraseñas/TOTP o claves FIDO como alternativas.

Empresa vs. consumo y el ángulo de política

  • Muchos coinciden en que la attestation y las políticas estrictas de hardware son apropiadas para algunos casos empresariales o de infraestructura crítica.
  • El debate se centra en si esos mecanismos se filtrarán a la autenticación web general de consumo.
  • Algunos ven esto principalmente como un problema de política (regulación, reglas bancarias, incentivos corporativos), no como un fallo único de las passkeys.
  • Otros argumentan que los estándares que facilitan el lock‑in y la attestation son peligrosos en sí mismos, independientemente del uso actual.