Hoy anunciamos los tokens de autenticación privados, un método completamente imperceptible y privado para verificar que quienes visitan tu sitio son usuarios reales. Los visitantes que utilicen sistemas operativos compatibles con estos tokens, incluidas las próximas versiones de macOS o iOS, podrán demostrar ahora que son humanos sin tener que completar un desafío CAPTCHA ni facilitar datos personales. De esta manera, se eliminará casi el 100 % de los desafíos CAPTCHA que se muestran a estos usuarios.
¿Cómo te afecta?
Si eres usuario de Internet:
Estamos haciendo que tu experiencia web móvil sea más agradable y más privada que la de otras redes al mismo tiempo.
No verás un desafío CAPTCHA en un dispositivo iOS o Mac compatible (¡más dispositivos próximamente!) que acceda a la red de Cloudflare.
Si eres un desarrollador web o de aplicaciones:
Sabrás que tus usuarios provienen de dispositivos auténticos y aplicaciones firmadas, verificadas por los proveedores de dispositivos directamente.
Podrás validar a los usuarios sin mantener SDK complicados.
Si eres cliente de Cloudflare:
¡No tienes que hacer nada! Cloudflare solicitará y utilizará automáticamente tokens de autenticación privados
Tus visitantes no verán desafíos CAPTCHA y les solicitaremos menos datos de sus dispositivos.
Tokens de autenticación privados
Durante el último año, Cloudflare ha colaborado con Apple, Google y otros líderes del sector para ampliar el protocolo Privacy Pass con la compatibilidad de un nuevo token criptográfico. Estos tokens simplifican la seguridad de las aplicaciones para los desarrolladores y los equipos de seguridad, y eliminan los enfoques heredados obsoletos basados en SDK de terceros para determinar si es una persona quien está utilizando un dispositivo. Funcionan para los navegadores, las llamadas API de los navegadores y las llamadas API dentro de las aplicaciones. A estos nuevos tokens los llamamos Tokens de autenticación privados. Esta mañana, Apple ha anunciado que va a incorporar estos tokens a iOS 16, iPad 16 y macOS 13, y esperamos que otros proveedores anuncien su compatibilidad en un futuro próximo.
Cloudflare ya ha incorporado los tokens de autenticación privados a nuestra plataforma Managed Challenge, por lo que cualquier cliente que utilice esta función se aprovechará automáticamente de esta nueva tecnología para mejorar la experiencia de navegación de los dispositivos compatibles.
Los desafíos CAPTCHA no funcionan en entornos móviles, pero los tokens de autenticación privados eliminan la necesidad de usar este recurso
Hemos escrito en numerosas ocasiones sobre cómo los CAPTCHA son una experiencia de usuario pésima. Sin embargo, no hemos hablado específicamente de lo mucho que empeora la experiencia del usuario en un dispositivo móvil. La tecnología CAPTCHA se desarrolló y optimizó para un mundo basado en el navegador. Se despliegan a través de un widget o iframe que generalmente es de tamaño único, lo que acarrea problemas de representación, o que la ventana de entrada solo sea parcialmente visible en un dispositivo. El espacio reducido de las pantallas de los móviles hace que la tecnología sea menos accesible y que la resolución de cualquier CAPTCHA sea más difícil. Además, la necesidad de representar archivos de JavaScript e imágenes ralentiza la carga de imágenes y consume un ancho de banda del cliente excesivo.
Dejando a un lado la usabilidad, los entornos móviles presentan un reto adicional, ya que cada vez se basan más en las API. Los CAPTCHA simplemente no pueden funcionar en un entorno de API en el que no se puede representar JavaScript o no se puede llamar a una WebView. Por lo tanto, los desarrolladores de aplicaciones móviles a menudo no tienen una opción fácil para desafiar a un usuario cuando es necesario. A veces recurren al uso de un SDK complicado para insertar un CAPTCHA directamente en una aplicación. Esta labor requiere insertar y personalizar el CAPTCHA, exige un mantenimiento y supervisión continuos, y aumenta la tasa de abandono. Por estas razones, cuando nuestros clientes deciden mostrar un CAPTCHA hoy en día, solo se muestra en el móvil el 20 % de las veces.
Hace poco publicamos cómo utilizamos nuestra plataforma Managed Challenge para reducir un 91 % el uso de desafíos CAPTCHA. Sin embargo, debido a que la experiencia CAPTCHA es mucho peor en el móvil, hemos estado trabajando de manera independiente en otras formas para reducir aún más el uso de desafíos CAPTCHA en el móvil.
Cuando los sitios no pueden desafiar a un visitante, recopilan más datos
Así que, o bien no puedes usar un desafío CAPTCHA para proteger una API, o la experiencia del usuario es demasiado deficiente para usarla en tu sitio web móvil. ¿Qué opciones quedan para verificar si un visitante es real? Una de las más comunes es mirar los datos específicos del cliente, lo que se conoce como huella digital.
Se puede pedir el IMEI del dispositivo y las versiones de los parches de seguridad, mirar el tamaño de la pantalla o las fuentes, comprobar la presencia de las API que indiquen un comportamiento humano, como los eventos interactivos de la pantalla táctil y compararlos con los resultados esperados para el cliente indicado. Sin embargo, toda esta recopilación de datos es cara y, en última instancia, no respeta al usuario final. Como empresa que se preocupa significativamente por la privacidad y por ayudar a mejorar Internet, queremos utilizar la menor cantidad de datos posible sin comprometer la seguridad de los servicios que ofrecemos.
Otra alternativa es utilizar las API a nivel de sistema que ofrecen comprobaciones de validación de dispositivos. Aquí se incluyen DeviceCheck en las plataformas de Apple y SafetyNet en Android. Los servicios para aplicaciones pueden utilizar estas API de cliente con sus propios servicios para afirmar que los clientes con los que se comunican son dispositivos válidos. Sin embargo, la adopción de estas API requiere cambios tanto en la aplicación como en el servidor, y puede ser tan difícil de mantener como los SDK.
Los tokens de acceso privados mejoran sustancialmente la privacidad al validar sin huella digital
Este es el punto fuerte de los tokens de autenticación privados. Al asociarnos con terceros, como los fabricantes de dispositivos, que ya tienen los datos que nos ayudarían a validar un dispositivo, podemos aislar partes del proceso de validación y confirmar los datos sin que nosotros tengamos que recopilarlos, tocarlos o almacenarlos. En lugar de interrogar directamente a un dispositivo, pedimos al proveedor del mismo que lo haga por nosotros.
En una configuración de sitio web tradicional con el proveedor de servicios CAPTCHA más común:
El sitio web que visitas conoce la URL, tu dirección IP y algunos datos adicionales del agente de usuario.
El proveedor de servicios CAPTCHA sabe qué sitio web visitas, tu dirección IP, la información de tu dispositivo, recaba datos de interacción en la página, y vincula estos datos a otros sitios donde Google te ha visto. De este modo, se crea un perfil de tu actividad de navegación tanto en los sitios como en los dispositivos, además de cómo interactúas personalmente con una página.
Cuando se utilizan los tokens de autenticación privados, los datos del dispositivo se aíslan y NO se intercambian explícitamente entre las partes implicadas (el fabricante y Cloudflare).
El sitio web solo conoce tu URL y dirección IP, datos que tiene que conocer para establecer una conexión.
El fabricante del dispositivo (verificador) solo conoce los datos del dispositivo necesarios para verificar tu dispositivo, pero no puede saber qué sitio web has visitado, y no conoce tu dirección IP.
Cloudflare conoce el sitio que has visitado, pero ignora cualquier información sobre tu dispositivo o interacción.
En realidad, no necesitamos ni queremos los datos subyacentes que se recaban para este proceso, solo queremos verificar si un visitante está falsificando su dispositivo o agente de usuario. Los tokens de autenticación privados nos permiten capturar ese estado de validación directamente, sin necesitar ninguno de los datos subyacentes. Nos permiten estar más seguros de la autenticidad de las señales importantes, sin obligarnos a analizar esas señales directamente.
Cómo los tokens de acceso privados compartimentan los datos
Con los tokens de acceso privados, cuatro partes se ponen de acuerdo para trabajar en conjunto con un marco común para generar e intercambiar tokens anónimos e infalsificables. Sin las cuatro partes en el proceso, los tokens de autenticación privados no funcionarán.
Un origen. Un sitio web, una aplicación o una API que recibe solicitudes de un cliente. Cuando un sitio web recibe una solicitud a su origen, este debe saber buscar y solicitar un token al cliente que realiza la solicitud. Para los clientes de Cloudflare, funcionamos como origen (en nombre de los clientes) y nos encargamos de solicitar y procesar los tokens.
Un cliente. Cualquier herramienta que el visitante esté utilizando para intentar acceder al origen. Normalmente será un navegador web o una aplicación móvil. En nuestro ejemplo, digamos que el cliente es un navegador Safari móvil.
Un verificador. Es la persona a la que el cliente pide que demuestre algo (por ejemplo, que un dispositivo móvil tiene un IMEI válido) antes de que se pueda emitir un token. En nuestro ejemplo, el verificador es Apple, el proveedor del dispositivo.
Un emisor. Es el único en el proceso que realmente genera, o emite, un token. El verificador hace una llamada API al emisor en el que el origen ha decidido confiar, indicándole que genere un token. En nuestro caso, Cloudflare será también el emisor.
En el ejemplo anterior, un visitante abre el navegador Safari en su iPhone e intenta visitar ejemplo.com.
Dado que Ejemplo utiliza Cloudflare para alojar su origen, Cloudflare solicitará al navegador un token.
Safari admite tokens de autenticación privados, por lo que hará una llamada API al verificador de Apple, pidiéndole que verifique.
El verificador de Apple comprobará varios componentes del dispositivo, confirmará que son válidos y luego hará una llamada API al emisor de Cloudflare (ya que Cloudflare, como origen, elige utilizar el emisor de Cloudflare).
El emisor de Cloudflare genera un token, lo envía al navegador, que a su vez lo envía al origen.
A continuación, Cloudflare recibe el token, y lo utiliza para determinar que no necesitamos mostrar a este usuario un desafío CAPTCHA.
Puede sonar un poco complicado, pero la mejor parte es que el sitio web no realizó ninguna acción en este proceso. La solicitud de un token, la validación, la generación del token y la aprobación se realizan en segundo plano por terceros que son invisibles tanto para el usuario como para el sitio web. Juntos, Apple y Cloudflare acaban de hacer esta solicitud más segura, han reducido los datos que van y vuelven y han evitado un desafío CAPTCHA al usuario. Y hemos hecho todo ello, recopilando e intercambiando menos datos del usuario que en el pasado.
La mayoría de los clientes no tendrán que hacer nada para utilizar los tokens de acceso privados
Para aprovechar los tokens de autenticación privados, todo lo que tienes que hacer es elegir Managed Challenge en lugar de Legacy CAPTCHA como opción de respuesta en una regla del firewall. Más del 65 % de los clientes de Cloudflare ya lo están haciendo. Nuestra plataforma Managed Challenge solicitará automáticamente un token a cada solicitud, y cuando el cliente sea compatible con los tokens de acceso privados, recibiremos uno. Cualquiera de tus visitantes que utilice un dispositivo iOS o macOS empezará a ver automáticamente menos desafíos CAPTCHA una vez que haya actualizado su sistema operativo.
Esto es solo el primer paso. Estamos trabajando activamente para que otros clientes y fabricantes de dispositivos utilicen también el marco de tokens de autenticación privados. Cada vez que un nuevo cliente empiece a utilizar el marco de tokens de autenticación privados, el tráfico que llegue a su sitio desde ese cliente empezará a solicitar tokens automáticamente, y sus visitantes verán menos desafíos CAPTCHA.
Muy pronto incorporaremos los tokens de autenticación privados a otros productos de seguridad. No te pierdas nuestros próximos anuncios.