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