Cómo el entusiasmo desmedido por las passkeys vuelve inútiles a las llaves de seguridad

• Si se generaliza la práctica de definir y exigir las passkeys como resident keys, las llaves de seguridad como Yubikey, Feitian y Nitrokey chocarán rápido con sus límites por el espacio de almacenamiento limitado
• Un non-resident credential funciona de modo que la llave de seguridad descifra el credential ID proporcionado por el Relying Party para obtener una clave privada específica de ese RP, así que dentro del dispositivo solo se guarda una master key
• En cambio, un resident/discoverable credential guarda la propia clave privada en la llave de seguridad, por lo que consume un slot por cuenta; Nitrokey admite 8 y Yubikey normalmente solo 20 a 32
• Las llaves de seguridad CTAP2.0 no pueden borrar resident keys de forma individual y requieren un reinicio completo; en ese proceso también cambia la master key, por lo que incluso las non-resident keys existentes dejan de funcionar
• Si los servicios y bibliotecas exigen resident keys por defecto, los usuarios con más de 150 cuentas tendrán que administrar varias llaves de seguridad y llaves de respaldo, lo que dificulta elegir libremente el autenticador que prefieran

---

Por qué la resident key está en el centro del problema

• La preocupación de que el entusiasmo desmedido por las passkeys pueda convertir las llaves de seguridad en dispositivos obsoletos tiene su núcleo en la resident key
• La idea de que una llave de seguridad soporta una cantidad “ilimitada” de cuentas suele depender del modelo de non-resident credential
• Como una resident key consume espacio real de almacenamiento dentro de la llave, a medida que aumenta la cantidad de cuentas los límites del dispositivo se vuelven evidentes de inmediato

Cómo funciona un non-resident credential

• En un non-resident credential, el Relying Party envía durante la autenticación el credential ID a la llave de seguridad a través del navegador
• El credential ID es un blob cifrado que solo la llave de seguridad puede descifrar, y el resultado del descifrado es la clave privada dedicada a ese Relying Party
• La llave de seguridad firma el challenge con la clave privada descifrada y devuelve la firma al navegador y al Relying Party
• En esta estructura, la clave privada no reside permanentemente dentro del enclave seguro y dentro de la llave de seguridad solo existe la master key
• El credential ID se cifra con AES-128 y se le aplica HMAC, por lo que se considera difícil de manipular o descifrar desde fuera
  • Se plantea la comparación de que, si AES-128 pudiera romperse hasta el punto de descifrar claves privadas sin la llave de seguridad, también estarían al alcance ataques contra el cifrado de TLS o SSH

La diferencia de los resident/discoverable credentials

• Una resident key o discoverable credential funciona guardando la clave privada dentro de la llave de seguridad
• Si el Relying Party envía una lista vacía de credential ID, la llave de seguridad busca qué clave puede usar para ese RP, la selecciona y firma
• Esta estructura no depende de recibir un credential ID externo y descifrarlo con la master key
• En cambio, como cada credential ocupa espacio dentro de la llave de seguridad, la cantidad de slots de resident key se convierte en el límite real de cuentas

userVerification es independiente de resident key

• Existe la confusión de que, para obligar a un credential a usar userVerification, necesariamente debe ser resident, pero ambos conceptos están separados
• Una llave de seguridad no solo confirma presencia con un toque; también puede verificar internamente un PIN o datos biométricos para confirmar que se trata del usuario real
• Este comportamiento se controla con el userVerification flag y funciona por separado de la residencia de la key
• Por lo tanto, aunque no sea una resident key, el dispositivo puede usarse por sí mismo como un autenticador multifactor

El almacenamiento de las llaves de seguridad y las limitaciones de CTAP

• Como las resident keys se guardan dentro del dispositivo, la cantidad de slots de la llave de seguridad es importante
  • Nitrokey admite 8 resident keys
  • Yubikey normalmente admite entre 20 y 32
  • Algunas llaves ni siquiera admiten resident keys
• El estándar CTAP implementado por la llave de seguridad también influye mucho en la capacidad de administración
  • CTAP2.1 y CTAP2.1PRE permiten administrar, actualizar y borrar resident keys individualmente
  • CTAP2.0 exige reiniciar completamente el dispositivo para borrar una resident key
• Un reinicio de un dispositivo CTAP2.0 también reinicia la master key, así que las non-resident keys existentes dejan de funcionar
• Es probable que muchas llaves de seguridad sean CTAP2.0 y, en el caso de Yubico, la versión de CTAP depende de la versión del firmware

El nombre passkeys y la expansión de la definición como resident key

• Apple anunció en 2022 una función de passkeys en macOS/iOS que usa Touch ID y Face ID como autenticadores WebAuthn
• Se considera que el nombre passkeys es más familiar para los usuarios que “webauthn authenticator” o “security key”
• Después surgieron varias interpretaciones mientras el significado de passkeys no quedaba claramente fijado
  • La biblioteca Rust WebAuthn y quienes implementan Relying Party definieron passkeys como el nombre de cualquier autenticador que el usuario pueda elegir
  • Algunos miembros de la comunidad llamaron passkeys a credentials sincronizados entre varios dispositivos
  • En la conferencia FIDO Authenticate apareció la definición de “passkey = resident key”, y desde entonces FIDO también usa esa definición en su FAQ
• Una razón por la que la definición de resident key atrae atención es su relación con una función futura del navegador: conditional UI
  • Si el credential es una resident key, se pueden autocompletar el nombre de usuario y el credential de WebAuthn
  • Eso ofrece una experiencia donde el usuario no tiene que escribir manualmente su nombre de usuario

Los problemas para el usuario que provoca exigir resident key

• Si una biblioteca de WebAuthn impulsa que todos los registros exijan resident key, las llaves de seguridad con almacenamiento limitado pueden llenarse rápidamente
• Por ejemplo, si alguien tiene más de 150 contraseñas guardadas en su gestor de contraseñas, convertirlas todas en resident keys requeriría al menos 5 Yubikeys
• Si además se consideran respaldos, podría terminar administrando entre 10 y 15 Yubikeys
• Eso produce una mala experiencia para quienes eligieron llaves de seguridad, y la exigencia de resident key en passkeys puede volver difícil el uso mismo de estas llaves
• En el marketing de llaves de autenticación FIDO se usan frases como “almacenamiento infinito de key pairs” o “sin límite en la cantidad de cuentas registradas”, pero eso puede ser cierto para non-resident keys y al mismo tiempo entrar en conflicto con la exigencia de resident key
• Uno de los objetivos del WebAuthn Work Group es permitir que los usuarios elijan libremente el autenticador que quieran sin desventajas, pero forzar resident keys no encaja con ese objetivo
• Como tipos de autenticador que sí funcionarían bien en un entorno de passkeys se mencionan Apple passkeys, Android passkeys, gestores de contraseñas con soporte WebAuthn, Windows con TPM 2.0 y navegadores basados en Chromium en macOS que usan Touch ID como si fuera un TPM

Posibles vías de respuesta

• Existe la opción de cambiar el comportamiento de rk=preferred para que no cree resident keys en las llaves de seguridad
  • Actualmente el Relying Party puede indicar el nivel de solicitud de resident key como discouraged, preferred o required
  • En la actualidad, rk=preferred crea resident keys incluso en autenticadores roaming como Yubikey, y en la práctica termina comportándose de forma parecida a rk=required
  • Si preferred se relajara a “crear resident key solo cuando el espacio de almacenamiento sea ilimitado”, Android/iOS sí crearían resident keys y no se consumiría el almacenamiento de las llaves de seguridad
  • El WebAuthn WG sigue siendo reacio a este cambio y, si un navegador quisiera implementarlo por su cuenta, en la práctica dependería de una decisión del equipo de Chrome
• Otra opción es exigir que las bibliotecas de passkeys usen rk=discouraged
  • rk=required puede excluir a las llaves de seguridad
  • rk=discouraged puede impedir que los usuarios de Android obtengan conditional UI
  • Se considera preferible eso antes que excluir las llaves de seguridad, ya que el nombre de usuario ya cuenta con mecanismos de autocompletado
• También existe la opción de pedirle a FIDO que exija la capacidad de almacenamiento de resident keys como parte de la certificación
  • Actualmente FIDO no obliga a una cantidad mínima de almacenamiento para los dispositivos autenticadores
  • Si FIDO quiere resident keys, entonces debería exigir que los autenticadores puedan guardar miles de resident keys

Conclusión

• La tendencia exagerada a ver las passkeys como resident keys puede impedir o dificultar seriamente que los usuarios de llaves de seguridad elijan en línea el autenticador que quieren
• El problema no está tanto en las passkeys en sí, sino en aplicar de forma general la exigencia de resident key a llaves de seguridad con almacenamiento y funciones de administración limitados

[GN⁺]

Comentarios de Hacker News

• Esto es un poco distinto del cifrado en sí, pero mi mamá me llamó en pánico porque no podía entrar a Gmail. Resultó que Google registró automáticamente su nuevo teléfono Android como passkey y lo cambió al método de inicio de sesión predeterminado, pero la interfaz era demasiado confusa
  Me parece excesivo esperar que uno tenga que pulsar la segunda opción para iniciar sesión con contraseña o que entienda qué es una passkey. Decía que “se envió una passkey a Android”, pero no llegó ninguna notificación al teléfono, y ni en 30 minutos pudimos resolverlo. Tampoco se podía borrar la passkey registrada automáticamente ni desactivar el flujo de autenticación predeterminado. La UX de Google es terrible, y confiar en una variante de Android modificada por Samsung en un teléfono barato como base de un sistema de autenticación a gran escala parece una decisión tonta

  • Google tiene el mismo problema con la verificación en dos pasos. Dice “Enviamos una notificación a tu S21”, pero en realidad, aun teniendo el S21 desbloqueado en la mano, 1 de cada 3 veces la notificación no llega o llega 5 minutos después
    Es solo uno de varios problemas que he tenido con Google últimamente. Antes lo evitaba más o menos por privacidad, pero ahora estoy haciendo todo lo posible por reducir al mínimo mi uso de Google. Mi negocio desapareció de Google Maps sin motivo alguno y tardé 2 semanas en volver a registrarlo, y fue imposible hablar con una persona. Cada correo de soporte da un número de teléfono, pero es para soporte de anuncios, así que no pueden hacer nada por una cuenta de negocio suspendida, y ni siquiera querían creer que el equipo de Google Business daba ese número como soporte. Tuve que repetir preguntas durante 30 minutos hasta que alguien de soporte de Google Ads admitió que no había forma de hablar con alguien de Google Business. Ahora ya soy básicamente un evangelista anti-Google
  • Por estas solicitudes no deseadas de confirmación de “enviamos una notificación a tu teléfono”, estoy considerando seriamente sacar mi negocio del ecosistema de Google. Lo entendería si de pronto iniciara sesión desde el otro lado del planeta, o si siempre usara Linux y el navegador fuera identificado como Windows, pero si usas un navegador centrado en la privacidad como ungoogled chromium, esto pasa cada vez que autenticas incluso desde la misma IP
    ¿Y si el teléfono se queda sin batería? ¿Si perdiste el teléfono y necesitas recuperar las credenciales del servicio de ubicación enviando un restablecimiento de contraseña por correo, pero no puedes iniciar sesión en el correo? A partir de ahí empieza el proceso de “responder preguntas”. Un algoritmo oculto y sin responsabilidad decide que ungoogled chromium en Linux es sospechoso, y si recuerdas mal respuestas a preguntas como “¿qué porcentaje del almacenamiento disponible estás usando actualmente?”, la recuperación del acceso queda a merced de la suerte. Para que conste, soy usuario de pago de Google
  • Pequeña corrección: la passkey no se “envía” a Android. El inicio de sesión en Gmail funciona haciendo que escanees el código QR mostrado en el navegador para demostrar que tienes la passkey en Android
    Aun así, entiendo perfectamente el punto. Tanto la UX como la terminología son confusas. Aunque cada paso dé explicaciones, la gente, especialmente cuando tiene prisa, está entrenada para saltarse el texto pequeño y pulsar el botón más grande y llamativo, así que eso no ayuda mucho. Es un problema realmente difícil a nivel de diseño de UX
  • Después de esto crucé una línea. Me hizo darme cuenta de que Google no toma decisiones pensando en el usuario. Gana dinero con los anunciantes, ofrece el servicio apenas lo suficiente para que los usuarios no se vayan, y lo mantiene apenas lo suficiente para bloquear a la competencia
    Mientras los usuarios no se vayan, a Google no le importa, ni necesita importarle. Si quieres algo distinto, necesitas un servicio cuyo costo no paguen los anunciantes. Si Google explota al usuario de una manera, Apple simplemente lo explota de otra, y elegir el veneno no es una opción
  • Siendo justos, esto no es tanto un problema de las passkeys en sí, sino más bien de que la UX del producto de Google es tonta. Si Google cambia de repente la UX de inicio de sesión de una forma a la que el usuario no está acostumbrado, la mayoría inevitablemente se va a confundir

• Como Apple no lo definió realmente, los opinólogos han llenado ese vacío para los usuarios que quieren saber “¿qué demonios es una passkey?”
  Yo había entendido que Apple definía las passkeys como pares de claves sincronizados con iCloud Keychain. En la presentación de la WWDC 2021 también se distinguían de las llaves de seguridad porque una passkey es algo que “siempre llevas contigo”, es decir, por la sincronización entre dispositivos y porque es “recuperable”. Después, parece que la definición se amplió a otros métodos de sincronización en la nube. Creo que este artículo hace una concesión equivocada. Las llaves de seguridad no importan[1]. Solo las usan muy pocos usuarios técnicos y unas cuantas empresas que realmente se toman la seguridad en serio. Si queremos mejorar la seguridad de la web, hay que sacar a la gente de las contraseñas, y el 99% de la población no va a usar llaves de seguridad a menos que lo obliguen. Las passkeys tienen mucho potencial para reemplazar las contraseñas, especialmente gracias a su integración profunda con el sistema operativo. No deberíamos optimizar la autenticación para el problema de que menos del 1% de los usuarios se quede sin ranuras para claves residentes. [1] Tengo 3 Yubikey, 3 llaves de seguridad de Yubico y 1 SoloKey

  • El objetivo no era el producto Apple Passkey, sino una iniciativa de toda la industria. Para cuando se lanzó en 2022, la definición ya se había relajado y pasó a parecerse más a una “experiencia”, por ejemplo, algo detectable que ofrece opciones de verificación del usuario
    El usuario puede elegir usar un proveedor de passkeys con respaldo y recuperación, y la parte confiable recibe esa señal. Puede usar esa señal para decidir si sugiere eliminar la opción de iniciar sesión con contraseña
  • En realidad, las passkeys las define la FIDO Alliance
    Según el estándar de FIDO, las passkeys reemplazan las contraseñas y permiten a los usuarios iniciar sesión en sitios web y apps de forma más rápida, fácil y segura desde varios de sus dispositivos. A diferencia de las contraseñas, las passkeys siempre son fuertes y resistentes al phishing. https://fidoalliance.org/passkeys/

• No entiendo por qué existe rk=required. Para empezar, ni siquiera debería existir como opción
  Por cosas como esta he seguido preocupado y escéptico con las passkeys y con quienes están detrás. Tienen la responsabilidad de diseñar el protocolo de forma que no se convierta en una herramienta útil para todo tipo de prácticas de mercado maliciosas con las que grandes empresas como Microsoft arruinan gravemente la seguridad y la compatibilidad, y matan la competencia. Pero la actitud que muestran una y otra vez en artículos y publicaciones se parece más a “que se jodan, les vamos a facilitar aún más el abuso”. No es solo un problema de las claves residentes; por ejemplo, la forma en que se maneja la atestación también puede abusarse fácilmente para hundir empresas

  • Parece que aquí la meta es convertir el teléfono en una passkey, y no usar nada más aparte de eso. Visto desde esa perspectiva, todo lo que aparece en el artículo tiene sentido
  • Me parece menos grave que el abuso de la atestación
    Si un servicio configura rk=required pero la plataforma no quiere activarlo, no lo soporta o simplemente no puede hacerlo, el proceso siempre fallará y ni siquiera se podrá registrar. Si el objetivo es incorporar usuarios y hacer crecer el negocio, parece una decisión contraproducente
  • Tengo curiosidad por saber a qué problema te refieres con eso de que “la forma de manejar la atestación puede abusarse fácilmente para matar empresas”

• No soy para nada una persona de seguridad ni de criptografía, así que este artículo me resultó muy difícil de seguir, y me imagino que a otros también les pasará
  Puede que para alguien con suficiente conocimiento previo estas preguntas suenen raras, pero me detenía cada una o dos frases. No entiendo cómo ni por qué “todo termina reduciéndose a una sola cosa: claves residentes”, ni cuál es la conexión con las passkeys o con los HSM. Cuando dice que “hay que entender qué son las claves detectables/residentes”, no me queda claro si significa que todas las claves residentes son detectables, que todas las detectables son residentes, o ambas cosas. También dice que “probablemente hayas visto que la mayoría de las llaves admiten cuentas ‘ilimitadas’”, pero no sé si ahí “llaves” se refiere a passkeys, a claves almacenadas en un HSM o a ambas. Y cuando dice “envías la clave envuelta a la llave de seguridad”, también me confunde si eso significa que la razón por la que un HSM puede aplicarse a cuentas ilimitadas es que puede guardar una clave envuelta dentro de otra clave

  • La idea central parece ser que WebAuthn se está empujando hacia un modelo de passkeys en el que cada sitio crea credenciales que consumen almacenamiento. El nombre del sitio que se muestra, el nombre de la cuenta de usuario, el handle del registro del usuario, la clave privada y otros elementos ocupan espacio de almacenamiento
    Un teléfono puede guardar 10 mil passkeys sin problema, pero una llave de hardware moderna quizá solo pueda guardar 25 en total en su flash disponible. La razón de necesitar ese almacenamiento es la capacidad de detección. Por ejemplo, en la página de inicio de sesión de GitHub.com, si pulsas el soporte para una passkey nueva, puedes iniciar sesión sin siquiera ingresar el nombre de la cuenta. El navegador ofrece una experiencia similar a la de un administrador de contraseñas, y así como las contraseñas en ese administrador, las passkeys también se convierten en registros locales de cuentas del sitio. Pero en WebAuthn también existen varios modos que no son passkeys. Las credenciales no detectables requieren proporcionar una lista de handles para una cuenta de usuario específica, y esos handles fueron entregados por la llave durante el registro. Al autenticarse, solo se presentan como opciones las credenciales que coinciden con esos handles. Las llaves de seguridad de hardware aprovechan esto para guardar dentro del propio handle el registro necesario para futuras operaciones criptográficas, y este modo no usa almacenamiento flash. Cuando el usuario ingresa su nombre de usuario, alguna API devuelve una lista de handles, y eso se aplica a la llave de seguridad para autenticar sin límites de almacenamiento. Sin embargo, muchos sitios adoptan políticas para no revelar si una cuenta existe. Seguro has visto procesos de recuperación del tipo “si esta cuenta existe, pronto recibirás un correo”. Desde la perspectiva del sitio, puede ser difícil aceptar que el proceso de inicio de sesión ofrezca una API capaz de detectar si existe una cuenta asociada a un nombre de usuario o correo, y cuántas credenciales se han registrado. Al final, parece más probable que aparezcan llaves de seguridad con 10 veces más almacenamiento antes de que los sitios adopten masivamente este procedimiento y eso afecte las limitaciones actuales del hardware
  • Coincido en que la argumentación del artículo es mala. El punto central es la afirmación de que es perjudicial que la parte confiable pueda especificar rk=required en el protocolo WebAuthN. La razón es que eso impide que mucho hardware TPM funcione como billetera o base de datos de passkeys
    Creo que la mayoría de los comentarios estará de acuerdo con eso. Pero eso no justifica la confusión que introduce el autor al dedicar la mitad del artículo a discutir la definición de passkey
  • El artículo da por sentado bastante conocimiento sobre FIDO2, así que es normal que resulte confuso
    Las passkeys se implementan sobre FIDO2 y, en particular, aprovechan la función de claves residentes de la especificación FIDO2. Los autenticadores de hardware FIDO2 no son exactamente HSM, pero se les parecen, y también hay dispositivos que son HSM y autenticadores FIDO2 al mismo tiempo, como Yubikey. En FIDO2, “clave residente” y “clave detectable” son sinónimos. La especificación usa “clave residente”, pero “clave detectable” también se usa con frecuencia, y es una de las terminologías confusas que creó FIDO. “Llave” aquí no se refiere a una passkey ni a una clave almacenada en un HSM, sino a un autenticador de hardware FIDO2 como una Yubikey, al que comúnmente se le llama “llave de seguridad”. Los autenticadores de hardware FIDO2 pueden registrarse en una cantidad ilimitada de cuentas porque, salvo cuando usan claves residentes, son básicamente sin estado y no almacenan nada. Cuando se registran en una cuenta, el dispositivo genera un par de claves como EdDSA, pero no lo guarda; en cambio, cifra la clave privada con una clave maestra integrada, por ejemplo una clave AES256. Luego envía a la parte confiable, como google.com, la clave pública en texto plano y la clave privada cifrada para que las almacene. Durante la autenticación, la clave privada cifrada, es decir, la “clave envuelta”, se envía al autenticador, se descifra dentro del dispositivo y se usa para crear una firma digital. Sin embargo, FIDO2 en realidad no especifica cómo debe implementarse una clave no residente, y la clave envuelta es solo una forma de hacerlo. FIDO2 solo exige que la clave privada pueda derivarse de forma segura a partir del ID de credencial, y el ID de credencial es datos arbitrarios que pueden o no ser una clave envuelta

• Me parece que se está viendo esto de forma demasiado severa. Si quieres aprovechar los beneficios del nuevo estándar de autenticación que elimina las contraseñas débiles y la reutilización de contraseñas para evitar el 99% de las intrusiones cotidianas en cuentas, también puede verse como que tienes que dejar atrás una Yubikey antigua que llevas usando desde 2013 y gastar 30 dólares para actualizarla

  • No entiendo por qué habría que forzar la actualización. Las claves no residentes también eliminan las contraseñas débiles y la reutilización de contraseñas. Las claves residentes solo añaden una mejora menor: que al conectar la llave, el servicio sabe a qué cuenta pertenece, y eso no parece una razón válida para desechar todos los dispositivos de autenticación existentes que ya se están usando
  • Revisé el manual técnico de la serie 5 y dice que solo soporta 25. Por ahora solo tengo 2, pero tengo muchas más TOTP que 25
    No sé cómo sea en los modelos Bio FIDO, pero si es parecido, puede que YubiCo no tenga un producto adecuado para una gran cantidad de claves residentes. Edit: Bio también tiene el mismo límite de 25
  • De hecho, me parece una interpretación demasiado generosa
    Las claves residentes compartidas no deberían existir salvo para usos temporales de corto plazo. Son una carga de responsabilidad, un riesgo de seguridad y fomentan malas prácticas de seguridad. El mejor ejemplo es TOTP, que desde el punto de vista de seguridad tiene muchos defectos. No deberías querer compartir o respaldar un secreto compartido entre varios dispositivos, pero como se puede hacer y las implementaciones flojas de autenticación de dos factores se volvieron el estándar en lugar de la excepción, en la práctica te empujan a hacerlo. Por cómo va la tendencia, parece que las passkeys van por el mismo camino defectuoso y hostil para el usuario
  • Aun así, no cambia demasiado. Mi llave solo puede guardar 25 claves residentes, pero tengo más de 25 contraseñas guardadas en el gestor de contraseñas
  • Me preocupa que en el futuro ya no haya otra opción más que aceptar esta “ventaja”. Si un sitio implementa el nuevo estándar de autenticación, ¿seguirá manteniendo como alternativa el esquema actual de usuario/contraseña/autenticación de dos factores?

• La autenticación basada en “algo que tienes pero que podrías perder” está fundamentalmente rota. Si pierdes el dispositivo, pierdes el acceso, o de lo contrario el punto más débil tiene que estar en otra parte, así que toda esa gran seguridad deja de tener sentido

  • Se puede imprimir códigos de respaldo o agregar una segunda llave de cajón. La idea en sí es excelente, pero el marketing es muy malo, el flujo de configuración para usuarios normales es raro, y también es mala idea empujar llaves con AirDrop o sincronización en la nube. El problema más importante es el costo de las llaves
  • ¿Las contraseñas no entran también en eso? La gente también pierde contraseñas con frecuencia
    Habrá que verlo en los resultados, pero si las passkeys se adoptan ampliamente, me parece que para la mayoría los bloqueos de cuenta serán menos frecuentes, no más

• Me da curiosidad por qué el almacenamiento de las llaves de hardware es tan limitado. ¿Cuánto costaría agregar junto a la llave algún medio de almacenamiento masivo al que pueda acceder el procesador seguro?
  Ese almacenamiento masivo, por supuesto, estaría fuertemente cifrado por el procesador seguro, y cuando se borre todo, esa clave también se eliminaría

  • Porque el almacenamiento resistente a manipulaciones es caro
    Desde una perspectiva de seguridad, incluso se podría decir que una llave de seguridad con 0 almacenamiento es la mejor llave de seguridad. Los protocolos que almacenan tokens de seguridad inyectándolos en una llave de seguridad o en un enclave seguro, en vez de derivarlos de secretos compartidos y similares, por lo general han tenido defectos graves. A veces son defectos de seguridad fundamentales, como en TOTP; otras veces son defectos de complejidad. Del mismo modo, nunca deberías querer compartir una llave de seguridad para HSK/autenticación de dos factores entre varios dispositivos. Si se filtra desde un dispositivo, todo queda comprometido. En su lugar, cada dispositivo debería tener su propia llave, y para el proveedor de login o del lado del servidor, esa sobrecarga es insignificante en el panorama general
  • Parece una decisión de diseño deliberada para mantener estos dispositivos lo más “tontos” posible. En cuanto agregas almacenamiento, se abre la misma superficie de vulnerabilidad que en cualquier otro medio de almacenamiento; luego viene capacidad de cómputo, y al final ya no tienes una Yubikey simple sino una computadora completa
  • Probablemente sí se podría aumentar el almacenamiento, pero mientras más le metas, más posibilidades hay de que falle. Las llaves actuales soportan un uso bastante rudo hasta que dejan de funcionar
    El almacenamiento pequeño también tiene la ventaja de ser un poco más fácil de auditar. Aunque, claro, para los estándares actuales, incluso ese tamaño pequeño podría estar empujando el límite de lo que realmente se puede auditar
  • Más que memoria limitada, se parece a algo diseñado desde el principio para no tener límite de memoria
    Si ves un TPM, cada vez que firma algo, la entrada es el dato a firmar y una clave privada sellada. La clave sellada es la clave privada generada por el TPM, cifrada simétricamente con una clave integrada dentro del TPM. Esa clave sellada se guarda en un medio de almacenamiento masivo y se le entrega al TPM en cada operación de firma. Gracias a este diseño, puedes tener tantas claves como permita el medio de almacenamiento masivo
  • También podría hacerse de forma modular. Algo que se vea como una memoria USB, pero que atrás tenga una ranura para insertar una llave de seguridad de formato pequeño, como una YubiKey Nano
    Cuando insertas la llave de seguridad en la ranura, la memoria USB le da almacenamiento a la llave de seguridad y ante la computadora se presenta como si fuera la llave de seguridad. Cuando no tiene insertada la llave de seguridad, funciona como una memoria USB normal. Normalmente dejarías puesta la llave de seguridad, pero si necesitas más almacenamiento, compras un módulo más grande, sacas la llave de seguridad del módulo actual y la conectas a la computadora, copias los archivos cifrados y luego los pasas al nuevo módulo antes de volver a insertar la llave de seguridad

• Para empezar, no sé si usar llaves de seguridad físicas como passkeys sea una buena idea. Las passkeys fueron pensadas como reemplazo de las contraseñas, y para eso parece necesario el atributo de dos factores que ofrecen el teléfono o la computadora de escritorio, que además de “algo que tienes” requieren “algo que sabes” o “algo que eres” para desbloquearse
  Me parece mejor dejar las llaves de seguridad físicas como autenticación de dos pasos adicional a las passkeys en ciertos contextos de alta seguridad. Sobre todo cuando la resistencia a la clonación es una función clave. Para ese uso, cuando llegas al segundo paso ya sabes qué cuenta intentas iniciar, así que no hace falta una clave residente. Además, creo que la función de autocompletado que ofrece la clave residente es importante para la UX de las passkeys. No tiene sentido sacrificar eso para mantener compatibilidad hacia atrás con unas cuantas llaves de nicho que solo usan los fanáticos de la seguridad. Claro, si hay una forma de mantener esa UX sin claves residentes, entonces estaría bien

  • Pienso más o menos lo mismo. La idea a la que todos han convergido ahora es tener una bóveda de seguridad de cifrado local confiable, y que haya que verificar la identidad ante ese sistema. Puede ser con una contraseña o con una llave
    Es más fácil confiar en que el gestor de contraseñas que elegiste es más seguro que asumir que todos los servicios del mundo donde creas cuentas son seguros o imposibles de phishing. Por eso, para cuando usas passkeys, muchas veces ya estás en un contexto más seguro donde ya estableciste tu identidad ante el sistema operativo o el gestor de contraseñas que posee las passkeys. Además, los lugares que no soportaban llaves de hardware ahora o hasta hace poco probablemente tampoco las habrían soportado en el futuro cercano. En cambio, una solución de passkeys es mucho más fácil de adoptar porque el costo de implementación se parece más a soporte de software, así que probablemente tenga mejor retorno sobre la inversión. Claro, esto aplica sobre todo a sitios web, y las passkeys se parecen más a unas “llaves SSH estandarizadas” para sitios web. Las llaves de hardware parecen más útiles como segundo factor para abrir de verdad la bóveda que contiene las passkeys, y ahí quizá también se necesite una contraseña. Creo que a las llaves de hardware todavía les queda algo de vida. He usado el flujo de inicio de sesión con passkeys como método principal en GitHub, Gmail y otros, y de verdad es muy, muy bueno
  • Los gestores de contraseñas ya volvieron inútiles a las contraseñas. No conozco ninguna de mis contraseñas, salvo la maestra. Las passkeys son una solución excesivamente compleja para algo que en realidad no necesitamos
    Bastaría con que el navegador tuviera una API HATEOAS simple a la que pudiera conectarse un gestor de contraseñas, y que la app web expusiera HTML que activara el navegador. Entonces el gestor de contraseñas decidiría cómo autenticar al usuario, es decir, el método que el usuario quiera, e inyectaría automáticamente el secreto de ese sitio web para que el usuario inicie sesión de forma automática. Si algo falla, se usa restablecimiento por correo electrónico. Entiendo que, desde la perspectiva de los sitios web que quieren una “seguridad muy elegante”, busquen algo más complejo. Pero el usuario debería poder activar opcionalmente un nivel más alto de seguridad. Por ejemplo, para la mayoría de los sitios web bastaría con un hash simple de contraseña si se asume que el gestor de contraseñas usa contraseñas aleatorias. Cualquier sitio web puede implementarlo, cualquier gestor de contraseñas puede implementarlo, y es mejor que el uso actual de contraseñas del 99% de los usuarios comunes. Eso puede ser el método de autenticación por defecto. Después, si quieren TOTP, OIDC, criptografía de clave pública, etc., el servidor puede anunciarlo y el cliente puede participar opcionalmente para continuar la autenticación. No hace falta que todos los sitios y todos los usuarios usen el método más seguro. Primero hay que facilitar subir la línea base de seguridad, y luego dejar que la gente elija poco a poco una seguridad más fuerte
  • Cuando haces autenticación sin contraseña (FIDO2) con una YubiKey, te pide un PIN antes de pedirte que toques el dispositivo. Si fallas demasiadas veces con el PIN, la YubiKey se bloquea y hace falta resetear el dispositivo, con lo que quedan invalidados todos los registros previos donde esa llave se usaba para autenticación
    No parece gran problema si alguien roba mi token de hardware. https://support.yubico.com/hc/en-us/articles/4402836718866-U...
  • Pensándolo bien, el problema central podría expresarse como “cómo autenticar a un ser biológico ante un sistema electrónico”
    Si usas una contraseña, la interfaz de autenticación es el teclado, y no hay garantía real de que quien la escribe sea en verdad la persona que dice ser. Las contraseñas dependen de conocimiento fácil de transferir, así que pueden extraerse de muchas maneras. Es mucho mejor mover la interfaz de autenticación a un esquema de dispositivo a dispositivo. En vez de asumir que ese conocimiento fácilmente transferible no fue transferido, se asume que el ser biológico puede controlar el dispositivo de autenticación, y la gente suele ser bastante buena en eso. También puedes reforzarlo aumentando la cantidad de canales de autenticación y limitar la autenticación entre el dispositivo y el ser biológico que se usará para autenticar al sistema remoto, como con FaceID. En el fondo, se siente natural asumir que un dispositivo como el teléfono o una llave es esa persona. En casa compartimos no solo la contraseña de Netflix, sino también una tarjeta de crédito. Por razones prácticas, dejamos una tarjeta junto con la llave de repuesto, y si alguien necesita comprar algo para la casa, cualquiera puede tomarla y usarla. Confiamos en que todos la usarán correctamente, todos saben el PIN, pero casi nunca hace falta porque el pago sin contacto es lo común. Es mucho más natural que andar rastreando gastos y luego ajustando cuentas entre nosotros. Probablemente sea ilegal y el banco cancelaría la tarjeta si se enterara, pero bueno. Los sistemas de TI necesitan urgentemente acercarse al comportamiento humano funcionando de una manera parecida al mundo real. La mayoría aguantamos porque estamos metidos en sistemas de TI, pero a la gente no tan técnica le cuestan incluso problemas cotidianos como cuál es la contraseña del iPhone, cuál la de iCloud, cuál la de Gmail, o por qué hay que meter un código en WhatsApp. De hecho, ni yo entendí Mastadon. Probablemente sería presa fácil de phishing en Mastadon, y seguramente escribiría cualquier cosa que la pantalla me pida ingresar
  • No es correcto decir que las passkeys son un reemplazo de las contraseñas

Las passkeys, fieles a su nombre, se apoyan en el estándar FIDO2 U2F, que fue desarrollado como un segundo factor. Las claves residentes son para autenticación de dos factores dentro del dispositivo, acompañadas de un PIN, y son un reemplazo funcional de las tarjetas inteligentes. Alguien, probablemente Apple, parece haber pensado que WebAuthn por sí solo era suficiente para convertirse en el único factor de autenticación. Sin claves residentes ni vínculo con hardware, las claves se mueven a través de iCloud, pero en el dispositivo están protegidas con TouchID/FaceID. Y a eso le pusieron la marca passkey. La autenticación de dos factores en sí no es el objetivo. El objetivo es una autenticación de usuario resistente al phishing, a la fuerza bruta y al credential stuffing, y que no sea tan difícil de implementar como las tarjetas inteligentes. FIDO2 lo logra. El problema con las implementaciones de Apple, Google y Microsoft no es que la seguridad a nivel de protocolo entre el sitio de autenticación y el dispositivo del usuario sea débil. Ese protocolo es el mismo. El problema es que ahora el sitio tiene que confiar en la cuenta personal de plataforma del usuario, en que el usuario la configuró correctamente, y en que la plataforma seguirá comportándose siempre de forma correcta para manejar adecuadamente los ataques contra esa cuenta personal.

• Para dar más contexto, dirijo una empresa de autenticación sin contraseñas respaldada por YC y la hemos desplegado en organizaciones grandes. Parece claro que las passkeys serán la respuesta para la autenticación sin contraseñas orientada al consumidor, pero todavía no parece que eso aplique igual en entornos empresariales.
  Las passkeys son excelentes para consumidores. Esto se debe a que buscan permitir por sí mismas el acceso de emergencia, respaldando las credenciales en otros dispositivos mediante iCloud por defecto o mecanismos como AirDrop. Técnicamente, los dispositivos que reciben compartidas estas credenciales no pueden ofrecer atestación. La atestación es la “prueba” de que un par de claves fue generado en un dispositivo específico como una Yubikey o un dispositivo de Apple. Fabricantes como Yubico envían sus llaves con pares de claves y certificados no extraíbles integrados, y como no existe una interfaz externa para acceder a ese par de claves, un administrador puede tener un alto grado de confianza en que se trata de una Yubikey real. Si no hay atestación y la clave puede compartirse, se ve dónde empiezan los problemas. Las empresas no quieren asumir el riesgo de que credenciales compartibles por AirDrop expongan el acceso a cuentas privilegiadas de empleados. Con Yubikey, el riesgo de robo digital es prácticamente nulo. Al final, las passkeys tampoco pueden usarse para desbloquear dispositivos o servidores. FIDO2, y más importante aún, los desarrolladores de sistemas operativos, todavía tienen mucho camino por recorrer para realmente acabar con las contraseñas. Hoy, en gran parte del mercado empresarial, Yubikey está cubriendo ese vacío, y algunos han gastado millones de dólares en hardware. Las passkeys en su estado actual serán difíciles de vender.

  • Passkey no es un término técnico, sino un término de experiencia. Por eso, si se usa en una discusión técnica, se desmorona un poco.
    Apple soporta passkeys, Android y Chrome también, Microsoft también y Yubikey también soporta passkeys. Pero funciones y restricciones como los procedimientos de autenticación para verificar al usuario y la posibilidad de clonación pueden variar enormemente. Las instituciones gubernamentales pueden soportar passkeys, pero permitirlas solo cuando se ofrezcan en dispositivos autenticadores con certificación FIPS que cumplan requisitos AAL2. Al menos por ahora, eso no vendrá de Apple o Google. Las empresas pueden optar por soportar passkeys generadas mediante software y configuraciones que ofrecen productos administrados por MDM, y Apple anunció soporte beta para eso. Aun así, si un servicio estatal para la ciudadanía intenta imponer un autenticador de hardware específico, puede sufrir mucho. Será difícil convencer a la gente de comprar hardware de más de 80 dólares, y como las tecnologías web están construidas alrededor de la elección del usuario, tampoco es probable que la API de WebAuthn y la experiencia de usuario se optimicen para ayudar a restringir esa elección.
  • ¿Qué pasa si Google o Apple bloquean una cuenta por error por razones absurdas como prevención de bots o detección de fraude?
  • las Yubikey 5 se pueden usar como passkeys

• Desde una perspectiva de seguridad, esto me parece una solución realmente pésima.
  Es una estructura de ensueño para que gobiernos y empresas como Apple y Google controlen la vida digital. Si usas contraseñas, estás en una especie de estado casi sin estado, así que aunque cruces una frontera teniendo una cuenta de correo personal o cualquier otra cuenta, nadie puede saber que posees esa cuenta, y es difícil que te obliguen a entregar el acceso, a extraer elementos de acceso del hardware o a bloquearte porque perdiste acceso al dispositivo. Aunque la clave maestra y cosas por el estilo se guarden en un TPM o elemento seguro, algunos gobiernos podrán acceder; será solo cuestión de años y capacidad de cómputo. En la mayoría de los casos, eso en sí mismo también se convierte en evidencia de que tienes las credenciales de cierta cuenta. A los fabricantes de dispositivos o sistemas operativos se les puede obligar fácilmente por parte de las autoridades a proporcionar acceso al área segura, ya sea de forma voluntaria o no.