Passkeys – Bajo el capó

Claves no residentes vs. claves residentes / passkeys

• Las claves WebAuthn/U2F no residentes derivan pares de claves por sitio a partir de un único secreto usando un identificador almacenado en el servidor; el token permanece casi sin estado, puede admitir sitios “ilimitados” y no filtra información sobre dónde se usa.
• Las claves residentes (“credenciales detectables” / passkeys) deben almacenar entradas por sitio en el autenticador para permitir inicio de sesión sin nombre de usuario, lo que crea límites de capacidad (docenas a unos pocos cientos de ranuras) y posibles problemas de privacidad (se puede consultar al autenticador si existe una cuenta para un dominio).
• Varios comentaristas sostienen que las passkeys son una regresión frente a contraseñas únicas y robustas + 2FA por hardware, especialmente cuando los sitios dejan de admitir WebAuthn no residente.

Compromisos entre seguridad y usabilidad

• Para usuarios con contraseñas débiles o reutilizadas, las passkeys se ven como una mejora importante (resistencia al phishing, sin filtraciones de contraseñas).
• Para usuarios preocupados por la seguridad que ya usan claves hardware y gestores de contraseñas, las passkeys pueden reducir la flexibilidad o la seguridad (factor único, sincronizables, attestation limitada).
• Algunos señalan que puedes evitar la enumeración de cuentas con claves no residentes enviando identificadores ficticios, así que “primero hacen falta contraseñas” no es estrictamente cierto.

Tokens de hardware vs. passkeys sincronizadas

• Claves de hardware: fuerte aislamiento, attestation, presencia física, PINs, buen ajuste para entornos regulados / de alto valor; pero el coste, el riesgo de pérdida de la clave, la gestión de claves por parte del usuario y el almacenamiento residente limitado son problemas reales.
• Las passkeys en teléfonos/entornos seguros con sincronización en la nube se ven como la única opción escalable para la población general; la mayoría de los usuarios no gestionará tokens separados ni copias de seguridad.
• Preocupa que el trabajo en FIDO/WebAuthn esté cada vez más optimizado para passkeys de plataforma, dejando a los autenticadores hardware itinerantes en un segundo plano.

Fragmentación del ecosistema y UX

• La compatibilidad de navegadores y sistemas operativos es inconsistente (por ejemplo, Firefox móvil, banderas de Chrome, UA sniffing); algunos sitios gestionan mal WebAuthn, restringen claves itinerantes o usan mal los flujos de UX.
• Los gestores de contraseñas admiten cada vez más passkeys (escritorio y móvil), pero la integración y los flujos (por ejemplo, prompts, autocompletado, fallback al navegador) siguen siendo ásperos.
• Explicar el básico “usa tu cara/huella para iniciar sesión” es fácil; explicar la recuperación, los cambios entre plataformas y cuándo todavía se requieren contraseñas se ve como algo difícil y poco especificado.

Attestation y control

• Los tokens hardware proporcionan una attestation fuerte; algunos sectores regulados dependen de ello.
• Las principales implementaciones de passkeys de plataforma han deshabilitado o limitado la attestation para credenciales sincronizadas, frustrando esos casos de uso.
• Otros argumentan que la falta de attestation es beneficiosa para la libertad del usuario y contra el control tipo DRM, destacando una tensión fundamental entre el control empresarial y la autonomía del usuario.