Cuando la mayoría de la gente piensa en criptografía, lo primero que suele venir a la mente es el cifrado: mantener la confidencialidad de la información. Pero igual de importante (o incluso más) es la autenticidad: garantizar que la información provenga realmente de una fuente auténtica.
Al visitar un sitio web, el servidor suele comprobar su identidad mediante un certificado de seguridad de la capa de transporte (TLS) autenticado por la Infraestructura de Clave Pública (PKI). Las contraseñas son la solución tradicional para la autenticación de usuarios, pero sufren ataques de phishing y filtraciones de datos. Aquí es donde entran en juego las PassKey (Claves de Acceso).
En lugar de explicar qué son las claves de acceso y por qué son mejores que las contraseñas (algo que ya se ha abordado muchas veces), esta publicación examinará la criptografía tras las PassKey, las garantías que ofrecen y las interesantes funciones criptográficas que se pueden realizar con ellas, como generar claves criptográficas y almacenar certificados. Es necesario comprender la criptografía tras las PassKey para implementar correctamente la autenticación segura.
También analizaremos la especificación principal de la clave de acceso, WebAuthn, y mostraremos cómo usar extensiones de mecanismos de PassKey para construir un sistema más complejo con diferentes capacidades.
Fundamentos de la criptografía de PassKey
En esencia, las PassKey son pares de claves que se utilizan para generar firmas digitales. Al registrar una clave de acceso, el sitio web guarda la clave pública y un identificador. Al autenticar a un usuario mediante una clave de acceso, el sitio web presenta un desafío y espera una respuesta firmada que incluya este desafío (y otros metadatos, como el identificador). El identificador se utiliza para buscar la clave pública, que a su vez verifica la firma.
Desde una perspectiva criptográfica, esto es bastante sencillo. La clave privada autentica al usuario, pero no se comunica al servidor ninguna información confidencial útil para un atacante. Si el desafío del servidor se genera correctamente (por ejemplo, como una secuencia aleatoria uniforme de 32 bytes), se evitarán los ataques de repetición. Dado que el servidor solo contiene una clave pública y el usuario no le envía información confidencial, no hay nada que pueda filtrarse en caso de un ataque informático.
Pero las firmas digitales por sí solas no son suficientes para resolver el problema del phishing. Si nos limitáramos a las primitivas criptográficas, los usuarios seguirían siendo vulnerables. Por ejemplo, sin medidas de seguridad adicionales, un atacante podría engañar a los usuarios para que firmen desafíos para el sitio web equivocado o reutilicen el mismo par de claves en varios sitios.
Por eso, las PassKey se basan en la especificación WebAuthn del W3C, que añade propiedades de seguridad cruciales más allá de la criptografía básica. Veamos cómo WebAuthn transforma estas sencillas primitivas criptográficas en un sistema de autenticación resistente al phishing.
WebAuthn
WebAuthn es la principal especificación detrás de PassKey. En pocas palabras, los usuarios acceden a un sitio web (parte confiante) a través de su navegador (agente de usuario WebAuthn) en un dispositivo como un portátil, un teléfono o un PC (dispositivo cliente). El navegador interactúa con un autenticador, una pieza de hardware o software que genera el par de PassKey y crea firmas digitales utilizando este par de claves.
En el diagrama anterior, puede ver cómo funciona la autenticación con clave de acceso:
- El sitio web solicita la autenticación a través del navegador.
- El navegador se comunica con el autenticador.
- El autenticador comprueba las credenciales y la presencia del usuario.
- El autenticador devuelve una respuesta firmada.
- El navegador reenvía esta respuesta al sitio web para su verificación.
(Esta interacción entre el navegador y el autenticador se describe con más detalle en otra especificación: el Protocolo de Cliente a Autenticador (CTAP) de FIDO Alliance).
Esta es una descripción simplificada; la especificación WebAuthn permite una mayor variedad de casos de uso (por ejemplo, todo podría funcionar a través de una aplicación móvil en lugar de un sitio web/navegador). Sin embargo, estos detalles no son relevantes para comprender cómo funcionan las PassKey con la criptografía.
Protección contra phishing
WebAuthn resuelve el problema del phishing mediante la vinculación de origen. La especificación requiere que los navegadores proporcionen el origen de la solicitud (es decir, el dominio del sitio web) al autenticador. El autenticador, a su vez, utiliza PassKey solo cuando el sitio web que realiza la solicitud coincide con el que la creó.
Esto significa que si crea una PassKey para bank.com, un sitio de phishing como fake-bank.com simplemente no podrá usarla; su autenticador rechazará la solicitud. Cada sitio web también obtiene su propio par de claves único, lo que elimina por completo el problema de la reutilización de contraseñas.
Además, la especificación solo permite orígenes que utilizan HTTPS, lo que significa que la solicitud proviene de un servidor con un certificado válido para el origen correspondiente.
Tipos de autenticadores
Generalmente, los autenticadores son "algo que se tiene". Todos los autenticadores pueden comprobar si un usuario está realmente presente durante la autenticación. Algunos autenticadores también pueden verificar al usuario según "algo que sabe", como un PIN, o "algo que es", como sus datos biométricos.
Existen dos tipos principales de autenticadores:
- Autenticadores de plataforma: se encuentran dentro del dispositivo del usuario.
- Ejemplos: iCloud Keychain, Google Password Manager, Windows Hello, 1Password
- Ventajas: convenientes, suelen incluir funciones de copia de seguridad en la nube
- Desventajas: vulnerables si el dispositivo se ve comprometido
- Autenticadores itinerantes: son dispositivos de hardware dedicados e independientes
- Ejemplos: YubiKeys, llaves de Seguridad Titan, llaves Feitian
- Ventajas: mayor aislamiento de seguridad, no se ven afectados por la vulneración del dispositivo.
- Desventajas: pueden perderse o dañarse, generalmente no tienen mecanismo de copia de seguridad
Si una plataforma permite la comunicación entre plataformas (como Bluetooth), sus autenticadores también pueden usarse como autenticadores itinerantes al comunicarse con otro dispositivo (por ejemplo, un smartphone). Para máxima seguridad en aplicaciones de alto valor, recomendamos usar llaves de seguridad de hardware dedicadas como autenticadores.
Algunos autenticadores muestran al usuario los detalles de la solicitud para la que generan una firma digital. En el caso de los autenticadores que no pueden hacerlo, el navegador mostrará estos detalles. Verifique siempre estos detalles antes de aprobar una solicitud de autenticación.
Cuando un usuario registra una clave de acceso en un sitio web, el autenticador genera una clave de acceso y un identificador (ID de credencial). El sitio web almacena la clave pública y el identificador y los vincula a la cuenta del usuario. El sitio web puede usar este identificador para indicar a los autenticadores a qué clave de acceso desean acceder.
Algunos autenticadores tienen mucho espacio de almacenamiento y almacenan todas las PassKey de los usuarios. Otros no, por lo que cifran la clave de acceso y la proporcionan al sitio web como identificador durante el registro. Cuando el sitio web desea autenticar a un usuario, proporciona el identificador al navegador, que a su vez se lo proporciona al autenticador, quien lo descifra y utiliza la clave de acceso. En esencia, el sitio web almacena la clave de acceso, pero al estar cifrada, su valor es limitado si el sitio web es atacado.
En teoría, se puede simplemente almacenar un par de claves criptográficas en un archivo, desarrollar un software que utilice este par de claves para operaciones criptográficas y simular que es un autenticador.
Pero ¿cómo pueden los sitios web saber si sus usuarios utilizan autenticadores seguros? Los autenticadores pueden comprobar criptográficamente ciertos datos sobre su origen, como quién los fabricó, generando una declaración de atestación cuando el usuario crea una clave de acceso. Esta declaración está respaldada por una cadena de certificados firmada por el fabricante. Esto es especialmente útil para usuarios empresariales, ya que permite a la empresa garantizar que todos los usuarios tengan autenticadores específicos que cumplan con ciertos requisitos de seguridad. Sin embargo, la atestación es opcional: la especificación WebAuthn no exige que los autenticadores la admitan.
Finalmente, como con cualquier factor de autenticación que se posee, una pregunta importante es: ¿qué sucede si se pierde o se rompe? En general, perder un autenticador implica perder todas las PassKey que controla.
Dado que las KeyPass son pares de claves criptográficas generadas aleatoriamente, no hay posibilidad de recuperación. La mayoría de los autenticadores de plataformas, como iCloud Keychain, Google Password Manager y 1Password, permiten realizar copias de seguridad de las PassKey sincronizándolas con la nube. Sin embargo, esto siempre implica una desventaja: las PassKey recuperables tienen una mayor superficie de ataque, ya que los atacantes podrían intentar obtenerlas a través del mecanismo de recuperación.
En general, es importante que los sitios web cuenten con un mecanismo de recuperación para cuando los usuarios pierdan el acceso a sus PassKey, teniendo en cuenta que los atacantes podrían atacar este mecanismo de recuperación.
Si bien el uso de autenticadores de plataformas con funciones de copia de seguridad reduce el riesgo de pérdida de PassKey, no lo elimina. Los usuarios que sean baneados de la plataforma perderán el acceso a sus claves de acceso, y la plataforma podría eliminarlas accidentalmente. Además, las plataformas también pueden permitir el uso compartido de PassKey o cuentas familiares, donde varios usuarios pueden acceder a las mismas. El sitio web debería advertir a los usuarios sobre estos riesgos, dependiendo del acceso que proporcione la clave.
Modelado de amenazas
A pesar de las afirmaciones de marketing que pueda haber escuchado, las claves de acceso no son una solución milagrosa para la seguridad. Veamos contra qué protegen realmente.
El modelado de amenazas de las PassKey muestra que protegen contra amenazas contra las que las contraseñas suelen proteger, a la vez que eliminan el riesgo de phishing y reutilización de contraseñas. ¡Una mejora significativa!
La Sección de Conformidad de la especificación WebAuthn hace una declaración muy contundente que implica que los sitios web, navegadores y autenticadores que cumplen con la especificación son "seguros" contra comportamiento malicioso. Esta afirmación simplifica demasiado la realidad de la seguridad. Estos son algunos escenarios de ataque reales que aún pueden ocurrir:
- Ataques basados en navegador: algunos autenticadores (como una YubiKey 5C) no tienen pantalla integrada y dependen completamente del navegador para mostrar a los usuarios el sitio web al que se están autenticando. Si el navegador está comprometido por malware o una extensión maliciosa, podría mostrarle "attacker.com" mientras que en realidad envía a su autenticador una solicitud para firmar en "google.com".
- Autenticadores comprometidos: la seguridad de las PassKey depende de que el autenticador proteja las claves privadas. Una clave de hardware falsificada, un software de autenticación con puerta trasera o malware que suplanta la identidad del autenticador integrado de su sistema operativo podría extraer secretamente sus claves privadas. Imagine comprar lo que parece ser una YubiKey de una fuente no confiable; podría estar enviando copias de sus claves a otra persona.
Las PassKey no protegen completamente contra la mayoría de las vulnerabilidades de los dispositivos de los usuarios, como navegadores maliciosos o malware. Sin embargo, sirven como limitadores de velocidad eficaces para los ataques, ya que cada firma requiere una interacción independiente del usuario con el autenticador. Además, las PassKey no protegen contra atacantes que puedan controlar el dominio del sitio web, ya sea mediante una toma directa o mediante el secuestro de subdominios.
Otro aspecto que los sitios web deben tener en cuenta son las colisiones de ID de credenciales. La especificación solo exige que sean probabilísticamente únicas, lo que significa que se generan aleatoriamente con una probabilidad extremadamente baja (pero no nula) de duplicación, similar a los UUID.
¿Por qué es importante esto? Cuando un usuario registra una clave de acceso, el sitio web almacena el ID de la credencial como identificador de la clave de acceso de ese usuario. Si un atacante pudiera registrar una clave de acceso con el mismo ID de credencial que su víctima, podría generar "confusión" en la autenticación.
Esto puede parecer improbable, pero considere estos escenarios:
- Un atacante que conoce el ID de credencial de una víctima (quizás obtenido del tráfico de red) podría intentar registrar su propia clave de acceso con ese mismo ID.
- Una aplicación de autenticación maliciosa podría generar deliberadamente ID de credenciales duplicados en lugar de seguir los requisitos de aleatoriedad del protocolo.
- Los errores de implementación podrían reducir la aleatoriedad efectiva en la generación de ID de credenciales.
La solución es sencilla: los sitios web siempre deberían rechazar los intentos de registro cuando el ID de credencial de una nueva clave coincida con uno ya existente en la base de datos. Esto crea una protección simple, por orden de llegada, contra conflictos de ID de credenciales.
Extensiones
WebAuthn también permite definir extensiones para los mecanismos utilizados para generar credenciales y realizar la autenticación. Básicamente, un sitio web puede solicitar el uso de una o más extensiones a través de la API de WebAuthn. El navegador y el autenticador procesarán estas extensiones si son compatibles e ignorarán las que no lo sean.
La especificación de WebAuthn enumera algunas extensiones definidas y enlaza con el registro de la Autoridad de Números Asignados de Internet (IANA) para obtener definiciones de más extensiones. Estas extensiones abarcan desde la compatibilidad con API anteriores hasta la compatibilidad con funcionalidades criptográficas completamente diferentes. Dado que esta entrada de blog trata sobre criptografía, estas últimas extensiones son las más interesantes.
Una de estas extensiones es la que la especificación de WebAuthn denomina prf (familia de funciones pseudoaleatorias), que se basa en la extensión hmac-secret definida en la especificación FIDO CTAP v2.1. Con la extensión prf, el autenticador puede calcular HMAC-SHA-256 utilizando una clave HMAC fija de 32 bytes generada aleatoriamente. La entrada para el cálculo de HMAC es el resumen SHA-256 de un prefijo WebAuthn fijo, seguido de la entrada proporcionada por el sitio web. Si bien esta extensión no es lo suficientemente flexible como para implementar algo como HKDF, es posible usarla para implementar HKDF Extract2.
Otra extensión similar se llama largeBlob y solicita a los autenticadores compatibles que almacenen un "blob grande" de datos opacos que el sitio web puede leer o escribir durante las aserciones de autenticación. El sitio web puede usarlo para almacenar cualquier dato (sensible), como certificados o claves criptográficas.
Por lo tanto, con estas extensiones, es posible derivar o almacenar claves criptográficas estáticas. Como se sugiere en el ejemplo de largeBlob, incluso se podría usar para el cifrado de extremo a extremo. Sin embargo, como ocurre con todas las aplicaciones de criptografía en la configuración del navegador, es extremadamente difícil, si no imposible, lograr una verdadera seguridad de extremo a extremo.
Normalmente, esto requiere que el sistema sea resistente a servidores maliciosos. La criptografía web se ejecuta en JavaScript proporcionado por un servidor, lo que significa que un servidor malicioso puede simplemente proporcionar JavaScript malicioso que extrae claves, envía mensajes descifrados al servidor, etc. Peor aún, un servidor malicioso puede hacerlo de forma muy selectiva, proporcionando JavaScript correcto a la mayoría de los usuarios, pero JavaScript malicioso a un usuario objetivo específico. Implementar la integridad de subrecursos para el código web (por ejemplo, almacenar el hash de todas las versiones publicadas con un tercero de confianza) y técnicas de transparencia binaria (por ejemplo, un registro públicamente verificable y a prueba de manipulaciones) son dos soluciones prometedoras para este tipo de problema.
Además, es importante tener en cuenta que la especificación considera todas las extensiones opcionales, lo que significa que no hay garantía de que los navegadores y autenticadores las admitan. Los sitios web deben comprobar si las extensiones están disponibles cuando las requieren; de lo contrario, los usuarios tendrán problemas para acceder a sus servicios. En el futuro, se espera que todos los navegadores y autenticadores principales las admitan, lo que podría mejorar la gestión de claves para la criptografía web.
En general, la especificación se encuentra en desarrollo activo y hay margen para muchas más extensiones interesantes. Entre las posibles extensiones se incluyen primitivas criptográficas adicionales (como esquemas de firma más avanzados y pruebas de conocimiento cero), pero los contadores monótonos serían una extensión interesante. Si bien no se trata directamente de una función criptográfica, los contadores monótonos podrían utilizarse para proteger el almacenamiento externo, como el almacenamiento en la nube con cifrado de extremo a extremo, de ataques de reversión.
El camino a seguir para las PassKey
Ha llegado el momento de adoptar las PassKey. Sus fundamentos criptográficos ofrecen sólidas garantías de seguridad que las convierten en la opción predeterminada para los sistemas de autenticación modernos cuando se implementan correctamente con WebAuthn.
Si bien no son una solución de seguridad perfecta, las claves de acceso eliminan muchas vulnerabilidades críticas que han afectado a las contraseñas durante décadas: nunca transmiten información confidencial a los servidores, no se pueden reutilizar en diferentes sitios y resisten el phishing mediante la vinculación de origen.
Consejo para usuarios y desarrolladores
Los usuarios deberían adoptar las claves de acceso y los desarrolladores deberían apoyarlas siempre que sea posible. Las claves de seguridad de hardware ofrecen la protección más sólida para aplicaciones de alto valor, mientras que los autenticadores de plataforma suelen ofrecer una mejor experiencia de usuario y funciones de copia de seguridad. Al autenticarse en dispositivos no confiables, utilice las PassKey de un dispositivo independiente con su propia pantalla para verificar las solicitudes de autenticación.
Los desarrolladores deberían implementar mecanismos de recuperación de cuentas, ya que las claves de acceso son pares de claves criptográficas que no se pueden reconstruir en caso de pérdida. Incluso los autenticadores de plataforma con funciones de copia de seguridad conllevan riesgos que los usuarios deben comprender.
Las PassKey pueden servir como primer factor de autenticación, segundo factor de autenticación o incluso múltiples factores de autenticación. Sin embargo, los desarrolladores deben considerar las claves de acceso dentro de su modelo de amenazas más amplio. Para protegerse contra servidores maliciosos, como en aplicaciones E2EE, implemente técnicas de integridad de subrecursos y transparencia binaria. A medida que WebAuthn evoluciona, nuevas extensiones habilitarán más aplicaciones criptográficas, aunque la compatibilidad varía según el navegador y el autenticador.
Fuente: TrailsOfBits