Credential stuffing : pourquoi votre connexion a l'air saine et fuit quand même

L'attaque, et pourquoi ce n'est pas de la force brute

Le credential stuffing ne devine pas les mots de passe. Il les rejoue. Quelqu'un prend des paires identifiant / mot de passe issues de la fuite d'un service sans rapport et essaie chaque paire une fois sur votre connexion, en pariant sur le fait qu'une part significative des gens réutilise ses identifiants.

Cette seule différence met en échec l'essentiel de ce que vous avez déployé. La force brute est bruyante : beaucoup de tentatives sur un compte, facile à limiter, facile à verrouiller. Le stuffing, c'est une tentative par compte sur des milliers de comptes, étalée sur des heures et avec rotation des adresses.

Le taux de réussite est faible — couramment cité entre un dixième et quelques pour cent — et c'est amplement suffisant. Sur une liste d'un million de paires, un dixième de pour cent fait mille comptes fonctionnels.

Et la connexion réussie est, selon toutes les mesures techniques dont dispose votre application, correcte. Le mot de passe était bon. Il n'y a rien à refuser.

À quoi cela ressemble dans vos journaux

Si cela passe inaperçu pendant des semaines, c'est qu'aucun signal isolé n'a l'air alarmant. Le motif n'existe qu'en agrégat.

• Le taux d'échec, pas le nombre d'échecs. Votre nombre absolu de connexions échouées bouge peut-être à peine, mais le rapport des échecs aux réussites se déplace — parce que les tentatives se répartissent sur des comptes qui, pour la plupart, n'existent pas ou ne correspondent pas.
• Une tentative par compte. Un limiteur de débit indexé sur le compte ne se déclenche jamais. Un limiteur indexé sur l'adresse ne se déclenche que si l'attaquant a oublié la rotation.
• La distribution des adresses. Les tentatives arrivent de pools de proxys résidentiels, c'est-à-dire d'adresses qui ressemblent à des clients ordinaires plutôt qu'à un centre de données.
• Un rythme trop régulier. Le trafic humain de connexion suit le rythme quotidien de vos clients. Une campagne de stuffing reste plate toute la nuit.
• Une hausse discrète des réussites depuis des adresses inconnues. C'est celle qui compte et celle sur laquelle personne n'alerte, parce qu'une connexion réussie n'est pas une erreur.

Pourquoi les contrôles habituels la manquent

Chacun de ces contrôles mérite d'exister et aucun n'arrête cette attaque à lui seul.

La limitation de débit est indexée sur la mauvaise clé. Les limites par compte ne se déclenchent jamais à une tentative par compte. Les limites par adresse sont battues par la rotation dans un pool de proxys résidentiels, qui est un service de grande consommation.

Le verrouillage de compte est ici pire qu'inutile, et activement dangereux. Il ne peut pas se déclencher à une tentative, et sur une connexion publique il permet à n'importe qui de désactiver les comptes de vos clients à la demande.

Les CAPTCHA sont un coût par tentative que l'attaquant a déjà budgété. Les services de résolution les facturent au millier, et à 0,1 % de réussite l'économie tient confortablement.

Les règles de complexité des mots de passe ne servent à rien. Le mot de passe rejoué est déjà valide — il satisfait les règles imposées par l'autre service, et probablement les vôtres.

L'authentification multifacteur est le seul contrôle qui casse réellement l'attaque, et elle vaut tous les efforts de déploiement. Elle n'aide pas non plus sur les comptes non inscrits, qui sur un produit grand public sont la majorité.

Ce qui l'attrape vraiment

Parce que l'attaque est invisible dans n'importe quelle requête isolée, la détection doit opérer au niveau de la session et de l'adresse.

Signaux au niveau de la session. Une campagne de stuffing automatise le formulaire : les champs se remplissent sans le rythme de la frappe, le focus se déplace d'une façon qu'une main humaine ne produit pas, la soumission arrive plus vite qu'une personne n'aurait pu remplir. C'est la même couche comportementale que lit toute détection invisible, et elle est visible dès la toute première tentative.

Empreintes de transport. L'outillage doit établir une connexion TLS, et sa pile se voit. Une empreinte JA3/JA3N qui ne correspond pas au navigateur que la session prétend être est un signal fort, et l'attaquant ne peut pas le corriger en modifiant un en-tête.

Réputation à travers les tentatives. Une tentative par compte ne vous donne rien par compte, mais la même adresse faisant une tentative sur quatre cents comptes différents est sans ambiguïté. Cet agrégat n'existe que si quelque chose note l'adresse au lieu de compter les requêtes.

Réputation inter-locataires. Les listes de stuffing sont rejouées contre de nombreux sites dans une même campagne. Une adresse qui a passé une liste sur la connexion de quelqu'un d'autre la nuit dernière mérite d'être arrêtée avant de s'attaquer à la vôtre — ce qui n'est possible que si cette connaissance est partagée.

Une installation défendable

Classé selon le poids de chaque étape dans le résultat.

Déployez la MFA et poussez l'inscription. Rien d'autre sur cette liste ne casse l'attaque à lui seul. Faites-en le réglage par défaut des nouveaux comptes et sollicitez les anciens après une connexion réussie depuis une nouvelle adresse.

Alertez sur les connexions réussies depuis des adresses inconnues. C'est peu coûteux, cela utilise des données que vous avez déjà, et c'est le signal qu'une campagne de stuffing a commencé à porter.

Notez la session, pas la requête. Les signaux comportementaux et de transport attrapent l'automatisation dès la première tentative, avant que le motif agrégé n'ait eu le temps de se former.

Appliquez à la passerelle. Une décision appliquée dans le JavaScript de la page est une décision que l'outillage de l'attaquant n'exécute jamais.

Vérifiez les identifiants contre les fuites connues, à la définition et à la connexion. Si le mot de passe rejoué figure déjà dans un corpus public, vous pouvez le refuser avant qu'il ne devienne le problème de quiconque.

Gardez votre liste d'autorisation à jour. Votre propre automatisation de QA et vos tests de charge ressemblent exactement à cette attaque, et les bloquer un jour de mise en production est un incident d'un autre genre.

Où se situe Karma

Karma couvre les points trois et quatre : il note chaque session à partir de signaux comportementaux et de transport, tient une base de réputation par locataire pour qu'une adresse répartie sur de nombreux comptes soit visible comme un seul acteur, et propose une liste de blocage partagée sur option pour qu'une liste rejouée à l'échelle du secteur soit connue avant d'atteindre votre connexion.

Le verdict part vers votre passerelle, qui arrête la requête avant même que votre application n'évalue le mot de passe — la tentative ne vous coûte donc rien et n'apparaît jamais comme une connexion réussie à instruire.

Cela ne remplace pas la MFA, et cette page ne le prétend pas. La MFA est le contrôle qui rend un mot de passe rejoué sans valeur ; tout ce qui précède consiste à arrêter le trafic qui teste quels mots de passe fonctionnent encore.