Fingerprinting WebAuthn : comment les API FIDO2 exposent votre identité

Introduction

WebAuthn (Web Authentication) est un standard W3C qui permet l'authentification sans mot de passe en utilisant la cryptographie à clé publique. Il permet aux utilisateurs de se connecter aux sites web en utilisant des capteurs biométriques, des clés de sécurité ou des authentificateurs de plateforme intégrés à leurs appareils. L'API alimente les passkeys, les clés de sécurité FIDO2 et les invites de connexion biométrique qui sont devenues de plus en plus courantes sur les sites web modernes.

WebAuthn est une amélioration significative pour la sécurité web, remplaçant les mots de passe par des identifiants cryptographiques résistants au phishing. Cependant, l'API expose aussi des informations sur les capacités d'authentification de l'appareil. Ces signaux de capacité varient selon la plateforme, le matériel et la version du navigateur, et ils peuvent être interrogés silencieusement sans interaction utilisateur ni permission. Cela fait de WebAuthn un vecteur de fingerprinting subtil mais efficace dont la plupart des utilisateurs sont complètement inconscients.

À mesure que les passkeys deviennent le remplacement standard des mots de passe, les requêtes WebAuthn deviendront encore plus courantes sur le web. Protéger vos signaux WebAuthn est un aspect de plus en plus important de la protection complète des empreintes.

Impact sur la vie privée

Le fingerprinting par capacité WebAuthn est subtil mais efficace. Les signaux ne nécessitent pas d'interaction utilisateur ni de permission. Un site web peut interroger la disponibilité de l'authentificateur silencieusement, avant tout flux de connexion, et utiliser les réponses pour construire un profil d'appareil. Cela se produit en arrière-plan sans aucune indication visible pour l'utilisateur.

Les préoccupations de confidentialité incluent :

• Identification de la plateforme : les requêtes de capacité révèlent si un appareil possède du matériel biométrique ou des puces de sécurité. Les appareils avec Touch ID, Windows Hello, des capteurs d'empreintes digitales, et ceux sans matériel biométrique produisent tous des réponses différentes.

• Détection de la version du navigateur : certaines fonctionnalités WebAuthn ont été ajoutées dans des versions spécifiques du navigateur. La présence et le comportement de ces fonctionnalités révèlent la plage de version du navigateur.

• Détection de navigateur headless : les environnements Chrome headless standard rapportent généralement qu'aucun authentificateur de plateforme n'est disponible, car il n'y a pas de matériel de sécurité dans un contexte headless. C'est l'un des signaux utilisés pour identifier les environnements automatisés.

• Matrice de support de fonctionnalités : la combinaison de la disponibilité de l'authentificateur, du support de médiation conditionnelle et d'autres supports de fonctionnalités crée une matrice qui varie par plateforme.

Une étude de 2023 examinant le déploiement de WebAuthn sur les 50 000 premiers sites Alexa a trouvé que plus de 20% des sites interrogeaient les capacités WebAuthn même lorsqu'ils n'offraient pas de connexion basée sur WebAuthn. Cela suggère que les requêtes de capacité sont utilisées à des fins au-delà de l'authentification, potentiellement incluant le fingerprinting et le profilage d'environnement.

Pourquoi cela concerne votre vie privée

Collecte silencieuse de données

Les requêtes de capacité WebAuthn sont complètement silencieuses. Il n'y a pas de demande de permission, pas de badge de notification et aucun indicateur visuel d'aucune sorte. N'importe quel site web peut déterminer les capacités d'authentification de votre appareil au moment où vous visitez, avant que vous n'interagissiez avec quoi que ce soit sur la page.

Profilage matériel

Les capacités d'authentification de votre appareil sont liées à son matériel. Ce profil matériel est persistant : il ne change pas quand vous effacez les cookies, passez en mode navigation privée ou utilisez un profil de navigateur différent.

L'avenir des passkeys

L'industrie se dirige rapidement vers les passkeys comme remplacement des mots de passe. Cela signifie que les requêtes de capacité WebAuthn deviendront encore plus courantes sur le web. Une protection proactive est essentielle.

Approches de protection courantes et leurs limites

VPN et serveurs proxy

Les VPN n'ont aucun effet sur les signaux de capacité WebAuthn. La disponibilité de l'authentificateur est une propriété matérielle locale qui n'a rien à voir avec le routage réseau.

Navigation privée et mode incognito

Les modes de navigation privée n'altèrent pas les réponses de capacité WebAuthn. La disponibilité de l'authentificateur de plateforme est la même en mode privé qu'en fenêtre normale.

Extensions de navigateur

Les extensions font face à des limites fondamentales avec la protection WebAuthn : la surface de détection des substitutions, l'impact fonctionnel sur les flux de connexion, et les limites de portée en dessous de ce que les extensions peuvent atteindre.

Désactivation de WebAuthn

Désactiver entièrement WebAuthn est en soi un signal fort. À mesure que les passkeys se répandent, l'absence de support WebAuthn est de plus en plus rare dans les navigateurs modernes.

L'approche de BotBrowser au niveau du moteur

BotBrowser contrôle les signaux de capacité WebAuthn au niveau du moteur du navigateur via son système de profils. Toutes les requêtes liées à l'authentificateur retournent des résultats cohérents avec la plateforme cible du profil chargé.

Configuration d'authentificateur basée sur le profil

chrome --bot-profile="/path/to/profile.enc" \
       --user-data-dir="$(mktemp -d)"

Le profil définit l'ensemble complet des capacités WebAuthn : disponibilité de l'authentificateur de plateforme, support de médiation conditionnelle, méthodes de transport supportées, support d'algorithmes et disponibilité des fonctionnalités. Toutes les valeurs sont capturées depuis de vrais appareils, garantissant la cohérence interne.

Cohérence multiplateforme

Exécuter un profil macOS sur un serveur Linux démontre la puissance du contrôle au niveau du moteur. Sans BotBrowser, un serveur Linux rapporte aucun authentificateur de plateforme. Avec un profil macOS chargé, les requêtes de capacité rapportent qu'un authentificateur de plateforme est disponible, cohérent avec un Mac ayant une authentification biométrique configurée.

Cohérence headless et avec affichage

BotBrowser maintient un comportement WebAuthn cohérent en mode headless et avec affichage. Les valeurs du profil sont appliquées indépendamment du mode d'affichage, éliminant la situation courante où les navigateurs headless rapportent des capacités d'authentificateur différentes des navigateurs avec affichage.

Configuration et utilisation

Utilisation CLI de base

La protection WebAuthn est automatique lors du chargement d'un profil :

chrome --bot-profile="/path/to/profile.enc" \
       --user-data-dir="$(mktemp -d)"

Intégration Playwright

const { chromium } = require('playwright-core');

(async () => {
  const browser = await chromium.launch({
    executablePath: '/path/to/botbrowser/chrome',
    args: [
      '--bot-profile=/path/to/profile.enc',
    ],
    headless: true,
  });

  const context = await browser.newContext({ viewport: null });
  const page = await context.newPage();

  const webauthnInfo = await page.evaluate(async () => {
    const results = {};
    if (window.PublicKeyCredential) {
      results.available = true;
      results.platformAuth = await PublicKeyCredential
        .isUserVerifyingPlatformAuthenticatorAvailable();
      if (PublicKeyCredential.isConditionalMediationAvailable) {
        results.conditionalUI = await PublicKeyCredential
          .isConditionalMediationAvailable();
      } else {
        results.conditionalUI = 'not supported';
      }
    } else {
      results.available = false;
    }
    return results;
  });

  console.log('WebAuthn signals:', webauthnInfo);
  await browser.close();
})();

Intégration Puppeteer

const puppeteer = require('puppeteer-core');

(async () => {
  const browser = await puppeteer.launch({
    executablePath: '/path/to/botbrowser/chrome',
    args: [
      '--bot-profile=/path/to/profile.enc',
    ],
    headless: true,
    defaultViewport: null,
  });

  const page = await browser.newPage();
  await page.goto('about:blank');

  const authInfo = await page.evaluate(async () => ({
    publicKeyCredential: !!window.PublicKeyCredential,
    platformAuth: window.PublicKeyCredential
      ? await PublicKeyCredential
          .isUserVerifyingPlatformAuthenticatorAvailable()
      : false,
  }));

  console.log('Authenticator info:', authInfo);
  await browser.close();
})();

Vérification

Après le lancement de BotBrowser avec un profil, vérifiez que vos signaux WebAuthn sont correctement protégés :

1. La disponibilité de l'authentificateur de plateforme retourne une valeur cohérente avec la plateforme du profil.
2. Le support de médiation conditionnelle correspond aux capacités de la version du navigateur du profil.
3. La cohérence headless/avec affichage est maintenue.
4. La différenciation inter-profils est présente. Des profils de plateformes différentes devraient produire des réponses WebAuthn différentes.
5. Les outils de test d'empreinte ne montrent aucune incohérence entre les signaux WebAuthn et les autres indicateurs de plateforme.

Bonnes pratiques

1. Utilisez des profils appropriés à la plateforme. Un profil macOS devrait rapporter la disponibilité de l'authentificateur biométrique. Un profil de bureau Linux devrait typiquement rapporter l'indisponibilité.

2. Vérifiez le comportement headless. Si vous exécutez en mode headless, confirmez que les signaux WebAuthn correspondent au comportement du mode avec affichage pour le même profil.

3. Considérez l'écosystème des passkeys. À mesure que les passkeys se répandent, assurez-vous que vos profils incluent le support approprié de médiation conditionnelle pour les versions modernes du navigateur.

4. Alignez avec les autres signaux de plateforme. La disponibilité WebAuthn devrait être cohérente avec les propriétés du navigator, le User-Agent et les autres signaux spécifiques au système d'exploitation dans le profil.

5. Combinez avec une protection complète. WebAuthn est l'un des nombreux vecteurs de fingerprinting. Pour une protection complète, utilisez un profil BotBrowser complet qui couvre toutes les surfaces d'empreinte.

Questions fréquentes

Le fingerprinting WebAuthn fonctionne-t-il sans interaction utilisateur ?

Oui. Les requêtes de capacité sont des requêtes passives qui ne nécessitent aucune interaction utilisateur, aucune permission et ne produisent aucune invite.

Les sites web peuvent-ils détecter que les signaux WebAuthn sont contrôlés ?

Si le contrôle est appliqué au niveau JavaScript, il peut être détecté par des techniques d'inspection. BotBrowser applique le contrôle au niveau du moteur, donc les méthodes natives elles-mêmes retournent les valeurs contrôlées sans aucune modification JavaScript à détecter.

Comment cela se rapporte-t-il aux passkeys ?

Les passkeys utilisent l'API WebAuthn. Les signaux de capacité contrôlés par BotBrowser sont les mêmes signaux que les implémentations de passkeys interrogent. Contrôler ces signaux garantit un rapport cohérent indépendamment de l'environnement hôte.

Les signaux WebAuthn diffèrent-ils entre les versions de Chrome ?

Oui. Certaines fonctionnalités ont été introduites dans des versions spécifiques de Chrome. Les profils BotBrowser sont versionnés et incluent l'ensemble de fonctionnalités WebAuthn approprié pour la version du navigateur cible.

Les environnements headless peuvent-ils être identifiés par WebAuthn seul ?

Avec le Chrome headless standard, oui. Le manque d'authentificateur de plateforme en mode headless produit une réponse qui diffère des navigateurs de bureau normaux. BotBrowser élimine cela en maintenant des signaux WebAuthn cohérents avec le profil en mode headless et avec affichage.

Résumé

Les signaux de capacité WebAuthn révèlent des informations sur la plateforme, le matériel et la version du navigateur qui servent de vecteur de fingerprinting persistant. La disponibilité de l'authentificateur de plateforme, le support de médiation conditionnelle et la matrice de fonctionnalités plus large varient par appareil et système d'exploitation, créant un signal distinctif qui ne nécessite aucune interaction utilisateur. À mesure que les passkeys deviennent le standard pour l'authentification web, ces requêtes ne feront que devenir plus courantes. BotBrowser contrôle tous les signaux WebAuthn au niveau du moteur via son système de profils, garantissant la cohérence multiplateforme et headless/avec affichage. Votre identité WebAuthn est authentique, stable et pleinement alignée avec chaque autre aspect de votre empreinte de navigateur. Pour une protection connexe, voir navigator properties protection, automation detection prevention, et comprehensive profile management.