L’impact des jetons d’accès privés (PAT) dans iOS 16 sur la détection des bots

Depuis des années, la validation des utilisateurs, c’est-à-dire le fait de déterminer qui est un véritable utilisateur et non un bot, constitue un défi constant en matière de cybersécurité. Pour ce faire, on utilise généralement l’un des nombreux systèmes CAPTCHA qui ont un impact négatif sur l’expérience et la vie privée des utilisateurs. Certains fournisseurs de CAPTCHA traditionnels collectent de nombreuses informations sur les usagers (adresse IP, détails du dispositif, interactions avec la page, etc.) et peuvent lier ces données à d’autres sites visités, créant ainsi un profil détaillé de l’historique de navigation des utilisateurs à travers différents sites et appareils.

Les jetons d’accès privés, ou Private Access Tokens (PAT), une nouvelle technologie de vérification des utilisateurs humains, ne nécessitent aucune entrée de la part de l’utilisateur. Ces jetons sont-ils la solution pour limiter les bots malveillants sans nuire à l’expérience de l’utilisateur, tout en protégeant sa vie privée ?

Dans cet article, nous explorerons les points suivants :

> Que sont les jetons d’accès privés ?

• • Architecture des PAT
  • Flux d’échange de données

> Quels sont les avantages des jetons d’accès privés ?

> Quelles sont les limites des jetons d’accès privés ?

> Pourquoi les PAT ne suffisent pas (et quels outils utiliser en complément)

> Comment DataDome traite les jetons d’accès privés

> Conclusion

Que sont les jetons d’accès privés ?

Les utilisateurs d’iOS 16 et de macOS Ventura peuvent désormais activer une nouvelle fonctionnalité d’Apple appelée jetons d’accès privés (PAT). Les PAT sont conçus pour vérifier les utilisateurs humains sans avoir à afficher de CAPTCHA.

Grâce à une combinaison des détails de l’appareil et de l’identifiant Apple de l’utilisateur, les PAT indiquent aux sites web si un utilisateur est légitime ou non. Les PAT sont une fonctionnalité développée dans le cadre du protocole Privacy Pass de l’IETF (Internet Engineering Task Force). L’IETF a créé le Privacy Pass Protocol pour permettre aux internautes de naviguer en toute sécurité, sans être constamment surveillés. Avec les PAT, les données des utilisateurs sont cachées et anonymisées tout au long du processus de requête et de validation des jetons (tokens), garantissant que ces derniers ne puissent pas être associés à un appareil spécifique.

Les PAT ont été conçus en mettant l’accent sur la confidentialité, de sorte que les jetons ne peuvent pas être liés à des utilisateurs spécifiques lors de la vérification sur un site. Comme l’a expliqué Apple lors d’une session de la Worldwide Developer Conference (WWDC) 2022 intitulée « Remplacer les CAPTCHA par des jetons d’accès privés »  : « Les serveurs qui reçoivent les jetons peuvent uniquement vérifier qu’ils sont valides, mais ils ne peuvent pas découvrir l’identité des clients ni les reconnaître au fil du temps. »

Les PAT sont conçus pour valider les utilisateurs comme étant humains lorsque des doutes subsistent pour un site web. Au lieu de cliquer sur toutes les cases contenant un certain objet ou de cocher une case indiquant qu’ils ne sont pas des robots, Apple utilise les PAT pour vérifier la légitimité des utilisateurs sans qu’ils aient besoin d’intervenir. Cela pourrait considérablement améliorer l’expérience utilisateur sur de nombreux sites et éliminer les inconvénients liés aux CAPTCHA.

Architecture des PAT

L’architecture des PATs repose sur la collaboration de quatre parties distinctes pour vérifier l’utilisateur à chaque requête :

• Origine : le site web, l’application ou l’API qui reçoit la requête du client. L’origine doit rechercher et demander un jeton au client.
• Client : l’outil utilisé pour effectuer la requête à l’origine, tel qu’un navigateur internet ou une application mobile.
• Médiateur : la partie qui identifie et authentifie le client en utilisant des informations telles que l’adresse IP, son nom d’utilisateur ou d’autres identifiants de l’appareil. Le médiateur anonymise ensuite le client et transmet les informations à l’émetteur.
• Émetteur : la partie qui génère et délivre les PAT au client pour le compte de l’origine. L’émetteur doit également anonymiser l’origine auprès du médiateur.

Flux d’échange de données

Lorsqu’un utilisateur effectue une action nécessitant une vérification (qui pourrait déclencher un CAPTCHA), comme la création d’un compte sur un site web ou une application mobile, le flux se déroule ainsi :

1. Le client soumet la requête à l’origine (le site ou l’application).
2. L’origine demande un jeton au client et le redirige vers l’émetteur.
3. Le client transmet la requête au médiateur.
4. Le médiateur vérifie et transmet les détails anonymisés du client à l’émetteur, en demandant un jeton.
5. L’émetteur vérifie les informations en fonction des politiques de l’origine.
6. L’émetteur génère et délivre le PAT au médiateur, qui le transmet ensuite au client.
7. Le client soumet enfin le PAT à l’origine.

Quels sont les avantages des jetons d’accès privés ?

Avec les systèmes CAPTCHA traditionnels, en particulier reCAPTCHA v3 de Google, la confidentialité des utilisateurs n’est pas une priorité. Le fournisseur de CAPTCHA collecte des informations telles que le site web visité, l’adresse IP de l’utilisateur, les détails de l’appareil, les interactions avec la page web, et peut relier ces données à d’autres sites visités par l’utilisateur.

Ainsi, si votre entreprise utilise un CAPTCHA traditionnel, le fournisseur peut créer un profil détaillé de l’historique de navigation de vos utilisateurs sur différents sites et appareils. Cela signifie que certaines entreprises sacrifient potentiellement la confidentialité de leurs utilisateurs et/ou clients dans le but de vérifier qu’ils sont bien humains.

Les PAT offrent un moyen de valider les utilisateurs sans leur imposer de résoudre un CAPTCHA. Les informations personnelles des utilisateurs ne sont pas collectées car les PAT sont autorisés de manière anonyme, avec un impact minimal sur l’expérience utilisateur. De plus, les développeurs peuvent plus facilement vérifier si l’utilisateur provient d’un appareil authentique (non rooté) avec une application signée (non modifiée).

Bien que des hackers puissent théoriquement créer de fausses identités ou utiliser plusieurs médiateurs liés à différentes identités vérifiées, l’utilisation des PAT devrait pousser l’écosystème de la cybersécurité à évoluer. D’autres atténuations mesures pratiques d’atténuation pourraient être mises en œuvre, notamment :

• permettre à un émetteur de connaître les propriétés d’un médiateur, en particulier quel identifiant client stable est authentifié par celui-ci, afin de déterminer si le médiateur est acceptable pour une origine ;
• permettre à une origine de choisir un émetteur en fonction des types de médiateurs acceptés par celui-ci, ou permettre à l’origine de communiquer ses exigences à l’émetteur désigné ;
• permettre à une origine de diriger un utilisateur vers un émetteur spécifique basé sur des propriétés visibles du client, telles que celles présentes dans la chaîne d’User-Agent HTTP.

Quelles sont les limites des jetons d’accès privés ?

La réputation du médiateur

Comme expliqué dans les sections 1.3 et 1.4 de la description des PAT par l’IETF, le médiateur est l’une des parties les plus importantes du processus de vérification, car il est le seul à pouvoir détecter les fausses identités clients dans l’architecture des PAT. L’émetteur doit donc se fier à la réputation du médiateur, et les jetons ne doivent être délivrés qu’à des médiateurs connus et réputés.

Cependant, un utilisateur pourrait « créer un nombre arbitraire d’identités clients qui sont acceptées par un ou plusieurs médiateurs, permettant à un utilisateur malveillant de contourner la capacité de l’émetteur à appliquer des politiques par client. » Par conséquent, le médiateur doit être en mesure de distinguer les vrais utilisateurs humains des bots.

Le médiateur est chargé d’« éliminer les fausses identités clients dans l’architecture des PAT. » Mis à part quelques mesures de sécurité comme la limitation du débit IP évoquées dans le projet de l’IETF, il y a très peu de détails sur la façon dont les médiateurs réussiront à identifier et écarter les fausses identités clients (ce qui n’est pas une tâche facile).

La configuration des requêtes

Le protocole des PAT exige également que le propriétaire du site web définisse quand demander un jeton. De ce fait, les PAT sont similaires à reCAPTCHA v3 en ce sens qu’ils demandent une charge de travail importante au webmaster. Comment déterminer quand demander un jeton plutôt que de simplement autoriser l’accès à un utilisateur ?

L’expérience utilisateur (UX)

Comme indiqué dans le projet de l’IETF, l’obtention et la validation d’un token peuvent ajouter une latence perceptible par l’utilisateur, car cela implique des interactions avec des serveurs tiers. Bien que cela puisse ne pas poser de problème si la vérification du token se fait en arrière-plan, cela peut nuire à l’UX dans d’autres cas.

Par exemple, si des web scrapers collectaient des informations sur vos pages produits, vous devriez trouver un moyen de les bloquer. Les scrapers distribués ont tendance à faire une requête par adresse IP sur différentes pages de projet. Si vous souhaitez arrêter ou identifier ces scrapers, vous devrez les bloquer à chaque requête de page produit effectuée depuis chaque adresse IP. Utiliser les PAT pour cela ajouterait de la latence à chaque chargement de page produit, ce qui affecterait également les utilisateurs légitimes.

Ainsi, pour protéger les sites web contre les scrapers distribués qui effectuent une seule requête par IP, il sera toujours important d’utiliser d’autres signaux en complément des PAT pour garantir une bonne expérience utilisateur (par exemple, des temps de chargement rapides).

Spécifique à l’appareil/système d’exploitation

Actuellement, seuls les utilisateurs Apple sur iOS 16 et/ou macOS Ventura qui acceptent d’utiliser les PAT ont accès à cette fonctionnalité de sécurité. Les appareils sous Android, Windows et les anciens appareils Apple ne pourront pas demander ou envoyer de PAT pour valider leur légitimité. Lorsque les jeton d’accès privés commenceront à être utilisés en production, la plupart des utilisateurs seront encore sur des appareils qui ne supportent pas cette nouvelle technologie.

Étant donné que la plupart des utilisateurs ont encore besoin d’anciennes méthodes de validation (telles que les CAPTCHA), les bots essaieront d’exploiter cette faille en se faisant passer pour des utilisateurs d’appareils qui ne prennent pas officiellement en charge les PAT.

Non liés aux appareils

Les PAT ne sont pas liés ou rattachables à un appareil spécifique, ce qui est une bonne chose en matière de protection de la vie privée. Cependant, cela réduit les avantages en termes de sécurité et sera certainement exploité par des bots. Les jetons d’accès privés pourraient être une option viable pour certaines pages ou certains points d’extrémité non critiques pour lesquels les entreprises pourraient privilégier l’expérience utilisateur plutôt que la sécurité. Mais il est essentiel de disposer d’une détection solide sur les points finaux critiques tels que la connexion, la création de compte et le paiement.

Les PAT seuls ne suffisent pas

Les PAT sont une alternative aux CAPTCHA pour valider un utilisateur, visant à vérifier l’authenticité d’un appareil. Cependant, ils sont assez limités, notamment en raison des restrictions liées au système d’exploitation. Les bots peuvent (et vont) se faire passer pour des utilisateurs d’appareils obsolètes ne supportant pas les PAT, légitimant ainsi leur refus d’envoyer des jetons.

Chez DataDome, nous observons de nombreux cas de bots opérant sur des appareils légitimes dans le but d’infiltrer des applications mobiles réelles. Les appareils bots disposent du même accès aux PAT que les véritables utilisateurs.

Il est important d’évaluer à la fois l’authenticité d’un appareil ou d’une application et l’humanité de l’utilisateur. C’est pourquoi Apple recommande même d’utiliser une protection contre les bots en temps réel en plus des PAT. Une solution efficace de protection contre les bots analysera plusieurs signaux, y compris les PAT, pour déterminer si un utilisateur est humain ou non.

Comment DataDome traitera les jetons d’accès privés

Les PAT, bien qu’encourageants, sont encore une technologie émergente. DataDome a l’intention de suivre de près leur développement au cours des prochains mois et années.

À mesure que les PAT évolueront, nous pourrions décider d’adapter la manière dont nous utilisons ce signal afin qu’il joue un rôle plus important dans la vérification des utilisateurs humains par rapport aux bots. Il est possible qu’à l’avenir, DataDome devienne l’origine pour nos clients — c’est-à-dire que nous demanderions les PAT aux utilisateurs via le médiateur et l’émetteur. (Voir le schéma d’exemple ci-dessous.)

Conclusion

Bien qu’ils représentent une avancée certaine pour la confidentialité et, dans de nombreux cas, pour l’expérience utilisateur, les jetons d’accès privés seuls ne résoudront pas les principaux problèmes de cybersécurité auxquels nous sommes confrontés aujourd’hui.

Les appareils et systèmes d’exploitation Apple plus anciens, ainsi que les utilisateurs non Apple, ne pourront pas utiliser les PAT pour valider leur authenticité. La majorité des utilisateurs se verront toujours proposer des défis CAPTCHA, et les CAPTCHA traditionnels continueront de collecter des données utilisateurs. Un autre problème potentiel réside dans la nécessité pour les médiateurs PAT d’être fiables et capables de distinguer eux-mêmes les utilisateurs humains des bots.

Les PAT ne sont pas un logiciel de détection des bots et ne peuvent pas, à eux seuls, atténuer le trafic de bots malveillants. Ils constituent un signal utile à inclure dans la décision de savoir si un utilisateur est humain ou non, mais ils doivent être utilisés avec une solution efficace de détection (et de protection) contre les bots.

En tant que nouvelle technologie, les PAT continueront d’évoluer avec le temps. DataDome intégrera ces jetons d’accès privés comme source de signal, aux côtés des nombreux autres signaux côté client et serveur déjà utilisés pour déterminer si une requête provient d’un bot ou d’un humain.