Credential stuffing dans la ligne de mire : comment VPN, rotation IP et limitation de débit protègent vos comptes en 2026

Qu’est-ce que le credential stuffing en 2026 et pourquoi c’est une plaie pour tous

Définition et différence avec le bruteforce

Le credential stuffing désigne les tentatives automatisées de connexion utilisant des combinaisons login-mot de passe issues de fuites sur d’autres services. Ne le confondez pas avec le bruteforce : ce dernier cherche le mot de passe par tâtonnements, alors que le stuffing ne fait que tester des combinaisons déjà connues dans des dumps. C’est comme utiliser une clé universelle trouvée : on ne force pas la serrure, on vérifie simplement si elle ouvre votre porte. Peu coûteux, bruyant et, malheureusement, efficace statistiquement.

En 2026, le taux de réussite moyen du credential stuffing varie entre 0,1 % et 2 % selon le secteur et la maturité des protections. Sur le papier, cela paraît faible, mais assez pour faire tomber des milliers de comptes à l'échelle de millions de tentatives. Les bots tournent 24/7, changent d’IP, émulent des navigateurs et ne fatiguent jamais. Les utilisateurs, eux, réutilisent leurs mots de passe. Notre vulnérabilité vient de notre paresse.

Plus Internet est avancé, plus les attaques deviennent rusées. En 2026, les bots imitent des comportements humains : ils bougent la souris, s’attardent sur les champs de formulaire, respectent les timers DOM. Ils paraissent « humains », naviguent entre les pages, génèrent des User-Agent plausibles, ajustent leurs empreintes TLS. Les protections « frontales » classiques s’essoufflent.

Pourquoi les attaques augmentent

Première cause : les fuites massives. Chaque nouvelle base de millions de mots de passe multiplie les chances de correspondances. Les fuites sont monnaie courante : forums, marketplaces, tous vulnérables, et les données finissent dans le dark web ou sur des chaînes Telegram. Deuxième cause : la disponibilité des outils. Un kit de stuffing coûte moins cher qu’un smartphone moyen et certains frameworks sont gratuits. Troisième cause : l’économie. Accéder à un compte tiers, c’est un accès direct à de l’argent facile : bonus, codes promo, points, cartes enregistrées, données personnelles.

Il ne faut pas sous-estimer le facteur technologique. En 2026, les bots exploitent headless Chrome, Playwright, des plugins stealth WebDriver, des capteurs de mouvement souris avec bruit, ainsi que HTTP/2 et HTTP/3 pour une gestion intensive des connexions. Ajoutez des solveurs CAPTCHA à base d’IA, des fermes de clics et des proxys résidentiels — vous obtenez une usine à connexions optimisée pour la conversion.

Objectifs typiques et scénarios de dommages

Les cibles varient : e-commerce pour vider les bonus, fintech pour transférer des fonds, SaaS pour voler des données, gaming pour revendre des biens virtuels. Les attaques ne sont pas toujours directes : parfois, le pirate « chauffe » le compte — teste la connexion, valide l’email, puis vend le accès. Les dommages combinent plusieurs aspects : prélèvements frauduleux, surcharge du support, ressources dédiées aux enquêtes, risques juridiques et réputationnels. Et les pertes liées aux faux blocages, quand la protection trop agressive pénalise les utilisateurs honnêtes.

Les pertes financières ne sont pas immédiatement visibles. D’abord on constate une hausse de la charge CPU et réseau, puis une montée des tickets au support, suivie d’une cascade de rétrogradations et réclamations auprès des banques, enfin des sanctions des partenaires de paiement. Dur ? Oui. Et ce n’est que la partie visible de l’iceberg, car restaurer la confiance des clients est le plus long combat.

Comment le VPN impacte le credential stuffing : mythes et réalité

Protéger l’utilisateur : chiffrement du trafic et confidentialité

Le VPN chiffre le trafic et le masque face au fournisseur ou au Wi-Fi public. C’est utile : moins de risques d’interception des sessions ou de substitution DNS. Pour un utilisateur qui se connecte depuis un café, le VPN ressemble à une assurance voyage : il ne supprime pas tous les risques, mais protège contre les ennuis classiques. En revanche, le VPN ne bloque pas directement le credential stuffing. La clé reste la réutilisation de mots de passe. Si votre mot de passe fuit ailleurs, le VPN ne vous protégera pas quand un bot le teste sur un nouveau service.

Cependant, le VPN améliore l’hygiène numérique. Il réduit le périmètre d’attaque des failles locales, diminue les MITM et nettoie une partie des « bruits » dans la télémétrie. En 2026, beaucoup de VPN personnels supportent des protocoles sécurisés comme WireGuard avec des handshakes rapides et des chiffrements modernes, rendant l’expérience quotidienne plus sûre et fluide.

Protéger l’entreprise : VPN comme périmètre de confiance et allowlist

Pour les entreprises, le VPN est un contrôle du périmètre. On peut encapsuler les consoles d’admin, les panneaux de modération, le back-office, les API internes critiques, et les points de connexion sensibles derrière un VPN d’entreprise avec allowlist d’IP. Le principe est simple : ne pas exposer les formulaires sensibles à tout le monde. Cela réduit drastiquement la surface d’attaque — les bots ne voient plus ces endpoints ou reçoivent un refus instantané.

En 2026, les équipes mûres construisent une approche hybride : VPN associé à un proxy aware de l’identité. On vérifie non seulement l’IP, mais aussi l’appareil, le certificat, le contexte de session. On combine avec des filtres géo et ASN pour que l’accès admin venant de zones à risque fasse l’objet de contrôles renforcés, voire soit bloqué. Ce n’est pas une solution miracle, mais combinée à la MFA et aux règles comportementales, c’est un rempart puissant.

Où le VPN ne protège pas, voire gêne

Le VPN ne stoppe pas le stuffing sur les formulaires publics destinés aux utilisateurs finaux. Les bots utilisent eux aussi VPN et proxies, parfois mieux que nous. De plus, bloquer aveuglément « tous les VPN » engendre des faux positifs : des clients en réseaux d’entreprise ou en déplacement ne peuvent plus se connecter. C’est un vrai problème pour le NPS. Par ailleurs, un filtrage agressif par ASN freine la conversion marketing — vous perdez des clients légitimes venant de data centers ou réseaux mobiles.

La conclusion est claire : le VPN est un élément de la stratégie, pas un substitut. Il détermine qui et d’où peut accéder aux surfaces critiques. Mais la bataille pour la résistance à la connexion se gagne avec des modèles comportementaux, la limitation de débit, la MFA, la protection frontend et une gestion intelligente des bots.

Rotation IP via VPN : quand, pourquoi et comment bien faire

IP résidentielles, mobiles, data centers

La rotation IP a ses bons et mauvais côtés. Les attaquants changent d’adresse pour éviter les blocages IP. Les défenseurs exploitent parfois la rotation contrôlée pour les tests, l’A/B testing anti-bots, la surveillance synthétique ou l’isolation du trafic par pools. Il faut bien comprendre les types : les IP data center sont rapidement marquées « suspectes », les mobiles et résidentielles sont plus proches des utilisateurs réels mais sont plus coûteuses et complexes.

Si vous vous défendez, gardez des pools propres pour les services critiques : webhooks, intégrations de paiement, SSO. Une IP sortante stable facilite les allowlists partenaires et réduit les faux positifs. En revanche, pour les tests internes, la rotation est utile : elle permet de voir comment votre WAF et limitation de débit réagissent aux réseaux, opérateurs et zones géographiques variés. L’essentiel est de ne pas mélanger les usages des pools, sinon vous vous bloquez vous-même.

Politiques de rotation : sessions sticky, pools, TTL

La rotation peut être brutale ou intelligente. Les sessions sticky assignent une IP par utilisateur ou navigateur pendant la durée de session. C’est proche du comportement réel et précieux pour tester l’anti-bot. La rotation avec TTL convient aux tâches de fond : l’IP change toutes les N minutes pour émuler un trafic client distribué. Les politiques de pool sont importantes pour la géofocalisation — par exemple, vous testez uniquement l’Europe de l’Est ou l’Amérique Latine.

Gardez en tête le cache CDN et les firewall stateful. Une rotation brutale couvrant des dizaines de pays en une heure peut provoquer une « attaque fantôme » et déclencher les protections de vos propres fournisseurs. Planifiez la rotation comme un horaire de trains : prévisible, avec marges temporelles, sans chaos.

Télémétrie et empreintes : TLS JA3, HTTP/2 et HTTP/3

En 2026, ce n’est pas qu’une question d’IP, mais aussi « d’aura » de connexion. L’empreinte TLS (JA3/JA4), le support des extensions, les suites de chiffrement, le comportement HTTP/2, QUIC pour HTTP/3 — tout cela dessine un profil client. Les attaquants choisissent des empreintes ressemblant à des navigateurs normaux. Les défenseurs, eux, contrôlent la cohérence : un navigateur qui se déclare Chrome mais envoie un TLS exotique pose question. L’association d’une IP propre et d’une empreinte douteuse déclenche des contrôles ou une réduction des quotas.

La rotation IP sans harmonisation des empreintes est peu efficace. Trouvez l’équilibre : une empreinte device stable avec une dynamique IP modérée paraît honnête, tandis que « chaque requête avec une nouvelle empreinte » sonne l’alarme.

Limitation de débit 2.0 : des limites intelligentes face aux réseaux de bots

Modèles de seau : token bucket, leaky bucket, sliding window

Les classiques restent d’actualité. Le token bucket gère les pics et lisse le trafic, leaky bucket régule la vitesse, sliding window compte précisément les événements sur une fenêtre temporelle. En pratique, on combine : limites strictes pour les requêtes « vides », plus souples pour les sessions établies, encore plus larges pour les appareils de confiance. Plus un requête semble risquée, moins elle dispose de « carburant » dans le seau.

Pensez grand angle. Limitez pas seulement par IP. Utilisez des combinaisons : IP + empreinte device + compte utilisateur + ASN + pays + User-Agent + URL + résultat. Trop d’échecs de connexion d’un même contexte ? On réduit la fréquence. Des comptes disparates liés à une même empreinte device ? On durcit. Adaptez les quotas au contexte.

Limites adaptatives selon le risque

Le vrai atout, c’est le scoring en temps réel. On prend en compte : nouveauté de l’appareil, historique des cookies, fréquence de changement IP, discordance fuseau horaire/géo, fraîcheur de l’empreinte navigateur, taux d’échecs de connexion. Plus le risque est élevé, plus le quota est strict. En cas extrême, une vérification interactive est déclenchée : CAPTCHA, WebAuthn, vérification e-mail ou code à usage unique.

En 2026, il ne s'agit pas forcément de « ML puissant ». Des règles pondérées et formules suffisent souvent. Par exemple : risque = w1*taux_échec + w2*nouveauté_IP + w3*âge_device + w4*risque_ASN. Si le risque dépasse un seuil, on réduit les limites par 10 et on force une double authentification. Point final.

Exemples concrets de règles et configurations

Exemple 1 : jusqu’à 5 connexions par minute par appareil et compte, 30 sur le domaine, 60 sur le pool IP si ASN est à faible risque. Pour les réseaux mobiles, seuils plus souples : jusqu’à 100 sur le pool IP, car les abonnés partagent souvent les adresses. Exemple 2 : après 3 échecs en 30 secondes — délai de 5 secondes, après 10 — CAPTCHA obligatoire, après 20 — blocage 15 minutes avec notification. Exemple 3 : si le User-Agent change de version plus d’une fois par session, on considère cela comme un camouflage et on réduit le quota à zéro.

Testez impérativement sur des données réelles. Lancez une canari : 5 % du trafic passent par les nouvelles règles, le reste par les anciennes. Comparez les taux de conversion et les plaintes. N’hésitez pas à revenir en arrière. Mieux vaut avancer par petits pas que de casser la moitié des connexions en une journée.

Protection multicouche des comptes : du mot de passe au sans mot de passe

MFA sans frustration : FIDO2 et passkeys

En 2026, les passkeys ne sont plus une curiosité. Leur support est mature sur desktop et mobiles, la synchronisation via écosystèmes est fiable. On délaisse les mots de passe quand on peut, ne les gardant que comme « pont ». Le secret : ne pas forcer, mais proposer. Après la première connexion réussie, affichez le dialogue natif : « Enregistrer la passkey ? » et expliquez succinctement le bénéfice. Le taux d’adoption monte en flèche, et la résistance au stuffing progresse fortement.

Quand la MFA est indispensable, privilégiez FIDO2 ou TOTP via app. Le SMS reste en secours, mais le risque d’interception et de SIM swap persiste. En cas de risque élevé, activez WebAuthn lors d’anomalies : nouveau navigateur, géo étrange, ASN suspect. Une MFA adaptative au risque, qui ne gêne pas la majorité mais freine les pirates.

Hygiène des mots de passe et gestionnaires

On ne peut pas imposer la perfection aux utilisateurs, mais on peut les guider. La validation côté serveur doit interdire les mots de passe les plus fréquents et ceux issus des fuites. En 2026, c’est la norme : lors de l’inscription ou du changement, vous vérifiez localement contre un dictionnaire « interdit » et les dernières fuites, sans jamais transmettre le mot de passe. Rappelez aussi les gestionnaires et rendez l’auto-complétion sûre et native.

Implémentez une politique business : par exemple, pour les rôles avec droits de remboursement ou paiement — passkey obligatoire. Pour les utilisateurs grand public — transition douce avec badge « Passkey recommandée », bonus ou support prioritaire. Les gens aiment les encouragements, pas les obligations sèches.

Renforcement des formulaires : CAPTCHA, proof-of-work et frictions intelligentes

Le CAPTCHA classique seul ne suffit plus, mais en cocktail, il fonctionne bien. Ajoutez-le contextuellement : beaucoup d’échecs entraînent un puzzle. Parfois un micro-délai d’1-2 secondes ou un léger proof-of-work navigateur suffit à flinguer l’économie du bot. Les gros réseaux surveillent le temps et le volume. Chaque opération supplémentaire réduit leur marge.

Gardez à l’esprit l’UX. Votre formulaire est la porte d’entrée de votre boutique. Qu’elle soit solide, mais sans tourniquet à chaque étape. Cachez la complexité derrière des règles intelligentes pour que les utilisateurs honnêtes trouvent tout simple et rapide. C’est possible.

Gestion des bots et analyse comportementale

Empreinte device et résilience

L’empreinte device rassemble des signaux : canvas, polices, WebGL, capteurs média, réglage d’heure, profil colorimétrique, TLS, même le bruit de rendu. En 2026, les attaquants randomisent beaucoup, mais la constance est difficile à fausser longtemps. On collecte l’empreinte, construit un graphe de liens et observe ses évolutions. Trop stable malgré changement de géo/ASN ? Suspicion. Trop chaotique en une session ? Pareil.

La résilience prime sur la précision. Oui, il y aura des faux positifs. Combinez l’empreinte avec d’autres facteurs : cookie binding, stockage local, mesures passives de timing. Mettez à jour vos librairies, car les techniques anti-detection évoluent sans cesse.

Modèles comportementaux et UEBA

User and Entity Behavior Analytics aide à distinguer « le légitime » de « l’intrus » par la routine : vitesse de frappe, navigation, heures d’activité habituelles, profondeur de navigation. Un bot peut simuler un clic, mais difficilement la manie d’ouvrir un panier avant le profil ou d’attendre 3-5 secondes avant de valider un paiement. Les modèles doivent être robustes. Basez-vous sur plusieurs patterns fiables et appliquez les règles progressivement : d’abord un pas supplémentaire, puis ralentissements, puis blocage.

Le risque calculé par ces modèles sert de multiplicateur à la limitation de débit et à la MFA. Un moteur sans contexte fait des erreurs, tandis qu’en synergie avec les règles, il tombe juste beaucoup plus souvent. C’est comme un bon barista et une machine à café : séparément ça passe, ensemble c’est top.

Obfuscation et protection front-end

Cacher les champs internes, renommer les paramètres, signer les requêtes côté client avec rotation des clés et liage à la session. La turbulence côté front complique la vie des scripts qui parsèment vos formulaires. Ajoutez des tokens dynamiques, des nonces à usage unique et des vérifications serveurs sur l’origine. Sans exagérer : le code doit rester maintenable. Opérez en couches avec journalisation pour identifier ce qui casse en cas de problème.

Mesures infrastructurelles : WAF, RASP, journalisation et canaris

Signatures WAF et règles basées sur le taux

Un WAF moderne en 2026 ne se limite pas aux signatures mais prend en compte le contexte. Activez des règles basées sur le taux sur les endpoints de connexion et récupération de mot de passe. Configurez des profils différents pour API et formulaires web : les API subissent plus souvent des attaques machine, elles méritent une protection spécifique. Surveillez les indicateurs : part de 401/429, temps de réponse, répartition géographique. Toute flambée déclenche un mode haute vigilance avec barrières renforcées.

Intégrez le WAF au système de scoring de risque. Si la gestion des bots évalue un contexte à haut risque, le WAF peut immédiatement envoyer un 429 ou déclencher une validation. Coordonnez les systèmes, pas de silos.

Canaris, comptes « miel » et bases d’ombre

Les honeytokens sont des pièges : logins ou marqueurs inexistants jamais utilisés par des vrais utilisateurs. Toute tentative dessus sonne l’alerte. Les comptes « miel » ressemblent à de vrais comptes, mais toute activité est anormale. Signal d’alerte précoce. Les bases d’ombre pour vérifier les mots de passe des fuites empêchent leur usage dès l’inscription. Vous détectez la menace avant production.

Mettez en place les notifications. Si une fuite est exploitée activement avec la série de logins, renforcez temporairement les limites, forcez la reconnexion et la MFA pour tous les utilisateurs « suspects ». La gestion rapide du mode est essentielle.

Surveillance des fuites dark web et alertes

Surveillez mentions de votre marque et domaine dans les fuites. Croisez automatiquement les dumps récents avec les hash de vos utilisateurs (sans exposer les mots de passe). En cas de correspondance, alertez vos clients et forcez le reset du mot de passe, idéalement avec une proposition de passkey. Soyez transparents : « Nous détectons un risque, aidons à sécuriser votre compte ». La franchise crée la confiance. Dans les moments difficiles, les gens apprécient la clarté.

Plan d’action pratique sur 90 jours

0–30 jours : audit express et premières victoires

Dressez la carte des surfaces : formulaires de login, API, SDK mobiles, intégrations partenaires. Activez une limitation de débit basique, mettez en place la journalisation, déployez des canaris, bloquez les mots de passe faibles. Faites un minimum : CAPTCHA selon risque, notifications de connexion sur nouvel appareil, suivi des 429 et 401. Organisez une réunion Dev, Sec et Support : responsabilités, escalades, métriques succès.

KPI initiaux : réduction des échecs de connexion de X %, baisse de la charge CPU et trafic de Y %, aucune hausse des plaintes UX. Ces petites victoires motivent et permettent d’obtenir le budget pour la suite.

31–60 jours : déploiement du périmètre VPN et des limites intelligentes

Placez l’admin et les API critiques derrière VPN et proxy identity-aware. Configurez des quotas adaptatifs tenant compte de l’empreinte device, ASN et géolocalisation. Ajoutez une MFA basée sur le risque et vérifiez la bonne intégration CAPTCHA. Lancez une analyse shadow des empreintes et comportements, sans perturber la prod, mais en collectant les signaux. Documentez tout et prévoyez des interrupteurs pour revenir vite en arrière si besoin.

Parallèlement, améliorez l’UX : proposez les passkeys dès la première connexion réussie, expliquez les bénéfices et affichez un statut clair dans le profil. Réduisez les frictions pour les « bons » appareils afin que les utilisateurs sentent que la sécurité travaille pour eux, pas contre eux.

61–90 jours : modèles ML et tests d’intrusion internes

Intégrez des modèles légers d’anomalies : isolation forest, gradient boosting sur les features session agrégées. Construisez un simulateur offline qui rejoue les attaques passées avec les nouvelles règles. Organisez une « red team » pour tenter de contourner vos protections avec IP résidentielles, navigateurs headless, randomisation d’empreintes. Ajustez les règles, colmatez les failles, mettez à jour les canaris.

À la fin, vérifiez vos KPI : la conversion login légitime est stable, les blocages efficaces ont augmenté, le support est moins saturé. Planifiez des audits trimestriels — les attaques évoluent, nous aussi.

Cas concrets 2026 : chiffres et conclusions

E-commerce régional

Problème : pics de stuffing avant promos, fuite de bonus, hausse des annulations. Solution : périmètre VPN pour admin, limitation de débit contextuelle, passkeys en caisse, CAPTCHA selon risque. Résultat : -72 % d’échecs de connexion, -48 % de vol de bonus, aucune hausse des plaintes pour frustration. Bonus : chauffe CDN disparu grâce à la filtration précoce du « bruit ».

Note : au lancement, une forte réduction des IP mobiles a provoqué une avalanche de plaintes. Corrigé en 24h — limites par appareil, amnistie du pool mobile. Leçon : les IP mobiles sont sournoises, pas de traitement uniforme.

Startup fintech

Problème : tentatives login via proxies résidentiels haut de gamme, signatures WAF nulles, transferts frauduleux de comptes volés. Solution : MFA adaptative basée sur le risque, binding device, honeytokens, mots de passe interdits, scoring comportemental, isolation API critique via VPN et mTLS. Résultat : -83 % de détournements réussis, durée moyenne d’attaque triplée, commissions fraude réduites chez le partenaire.

Note : plaintes clients sur vérifications fréquentes en déplacement. Ajout de « appareils de confiance » et « pays de confiance », améliorations UX. La fraude baisse, la satisfaction monte. C’est l’équilibre parfait.

SaaS B2B

Problème : connexions depuis data centers et génération automatisée de sessions pour fuite de données. Solution : proxy identity-aware, allowlist sur egress IP clients, passkeys pour admins, frontières par rôles, délais personnalisés et tags de risque. Résultat : -90 % de connexions anormales, réduction des coûts de support infra, logs clairs pour audit.

Note : équipe enfin sereine lors du déploiement. Ça peut paraître trivial, mais la santé mentale est un vrai levier. Moins d’incendies, meilleure qualité de travail.

Erreurs fréquentes et anti-patterns

Blocage excessif par IP

Bloquer tous les VPN est tentant mais nuisible. Vous perdrez des clients, aurez des paniers vides et des analyses biaisées. Privilégiez la précision : risque ASN, scoring comportemental, empreintes, quotas adaptatifs. L’IP n’est qu’un signal parmi d’autres.

Croyance aveugle au CAPTCHA

Le CAPTCHA n’est pas une armure. C’est un obstacle contournable avec des fermes ou solveurs. Utilisez-le dans un système : actif selon risque, avec délais, couplé à WebAuthn. Seul, il fait plus mal au bon utilisateur qu’au bot.

Ignorer les SDK mobiles

Les applis mobiles sont un univers à part. Les bots savent émuler les SDK, falsifier la télémétrie et extraire les tokens. Appliquez les bindings côté app, vérifiez l’intégrité, faites l’attestation d’environnement et la vérification serveur des signatures. Et synchronisez bien avec le web pour éviter les trous sur les ponts.

FAQ

Le VPN protège-t-il du credential stuffing ?

Pas directement. Le VPN chiffre le trafic et prévient les interceptions, mais le stuffing exploite des mots de passe volés. Seuls un mot de passe unique, un gestionnaire ou idéalement les passkeys offrent une vraie protection. Combiné à la MFA, c’est très robuste.

Faut-il bloquer toutes les connexions VPN et proxies ?

Non. Trop de faux positifs et des clients perdus. Préférez un modèle adaptable : évaluation du contexte, limites intelligentes, validation d’empreintes, signaux comportementaux. Bloquez seulement les sources manifestement toxiques.

CAPTCHA ou passkeys ?

Ce n’est pas l’un ou l’autre. Les passkeys sont une arme stratégique contre le stuffing, le CAPTCHA un garde-fou tactique selon le risque. Le combo parfait : passkeys pour les bons utilisateurs, CAPTCHA et délais pour les scénarios suspects.

Comment configurer la limitation de débit sans nuire à l’UX ?

Démarrez doucement et de manière contextuelle. Limites sur requêtes vides et échecs de connexion d’abord, puis quotas adaptatifs basés sur le risque. Testez sur 5–10 % du trafic, surveillez la conversion et les retours. Prévoyez une coupure rapide.

Le device fingerprint est-il utile en 2026 ?

Oui, mais pas seul. Utilisez-le avec IP, comportement, historique session et scoring risque. Mettez régulièrement à jour les technologies, l’anti-detection progresse vite.

Quelles solutions donnent effet rapide ?

Victoire rapide : limitation basique, mots de passe interdits, CAPTCHA contextuel, notifications nouvelle connexion, périmètre VPN admin, proposition passkeys dès première connexion. Les résultats se voient en semaines.

Pourquoi les passkeys sont-elles cruciales maintenant ?

Parce qu’en 2026, elles sont largement supportées par les appareils et navigateurs, avec une UX native et efficace. Elles réduisent la dépendance aux mots de passe et cassent presque toute l’économie du stuffing, reposant sur une authentification cryptographique difficile à falsifier.