Chez un éditeur SaaS, le credential stuffing est un problème de produit avant d'être un problème de sécurité interne. Les couples identifiant / mot de passe rejoués ne visent pas les comptes de l'éditeur mais ceux de ses utilisateurs finaux. L'attaque se mesure donc en comptes clients compromis, en tickets de support, en coût d'infrastructure absorbé pour rien, et en confiance perdue — alors que le service n'a subi aucune fuite.
Le point d'entrée réel : l'API, pas la page de connexion
Les campagnes ne passent plus par le formulaire web. Elles ciblent directement le point de terminaison d'authentification de l'API, plus rapide, plus prévisible et généralement moins instrumenté que l'interface. Trois surfaces sont concernées et rarement protégées au même niveau.
- L'API d'authentification principale, utilisée par l'application web et mobile.
- Les points de terminaison secondaires : rafraîchissement de jeton, vérification d'existence de compte, réinitialisation de mot de passe. Le point de vérification d'existence est le plus précieux pour l'attaquant : il permet de nettoyer une liste avant de tester les secrets.
- Les anciennes versions d'API maintenues pour compatibilité, souvent exclues des contrôles ajoutés depuis.
Un audit utile commence par une question simple : combien de chemins distincts permettent de savoir si un identifiant existe dans le système ?
Le coût, même quand l'attaque échoue
| Effet | Manifestation | Visible par | Réduction possible |
|---|---|---|---|
| Charge d'infrastructure | Pics de trafic sur l'authentification | Équipe technique | Limitation en amont, réponse graduée |
| Coût de vérification | Envois de messages, appels de services tiers | Finance | Contrôle avant appel externe |
| Pollution de la base | Comptes créés ou altérés | Produit | Contrôle à l'inscription |
| Blocages en cascade | Utilisateurs légitimes verrouillés | Support | Limitation par empreinte, pas par compte |
| Prises de contrôle | Comptes clients détournés | Client, presse | Filtrage des secrets compromis, MFA |
| Perte de confiance | Questionnaires de sécurité, churn | Direction | Communication et posture documentée |
La quatrième ligne mérite un arrêt. Une politique de verrouillage par compte transforme une campagne de rejeu en déni de service sur les utilisateurs légitimes : il suffit à l'attaquant d'échouer volontairement pour bloquer une base entière. La limitation doit donc porter sur l'origine et l'empreinte, pas sur le compteur d'échecs du compte visé.
Détecter quand l'attaquant ressemble à un client
Les campagnes actuelles passent par des réseaux d'adresses résidentielles et étalent les tentatives. Le volume par adresse devient inexploitable comme signal. Ce qui reste discriminant relève du comportement.
Une authentification légitime est précédée d'un chargement de page, d'une frappe au clavier avec des intervalles irréguliers, et suivie d'une navigation. Une tentative automatisée arrive sans contexte, avec des intervalles trop réguliers, et disparaît après la réponse. La cohérence entre l'agent utilisateur annoncé et les capacités réellement observées du client est un autre marqueur solide.
La réutilisation d'une même empreinte sur des comptes sans lien constitue le signal le plus fiable : c'est une propriété de l'attaque, pas de l'attaquant, donc difficile à contourner.
Les décisions produit qui font la différence
Refuser les secrets déjà compromis. À l'inscription et au changement, vérifier le mot de passe contre les corpus de fuites publiques. C'est la mesure la plus rentable, et elle protège les utilisateurs contre leur propre réutilisation.
Uniformiser les réponses. Même message, même délai, même code de retour, qu'un compte existe ou non, qu'un secret soit valide ou non. Cette discipline retire à l'attaquant la capacité de qualifier sa liste.
Réponse graduée plutôt que blocage binaire. Trafic suspect : ralentissement, puis épreuve supplémentaire, puis blocage. Le blocage immédiat renseigne l'attaquant sur vos seuils.
Proposer une MFA que les clients activeront réellement. Un dispositif optionnel enfoui dans les paramètres ne protège personne. L'activation par défaut sur les comptes à privilèges d'un tenant est une décision produit plus efficace que n'importe quelle campagne d'incitation.
Offrir le passwordless. Le rejeu suppose un mot de passe à rejouer. Les passkeys FIDO2/WebAuthn suppriment cette cible et résistent en outre au relais grâce à la liaison à l'origine. Une approche IDless va plus loin en supprimant aussi l'identifiant, ce qui retire tout point d'application à une liste de fuites : c'est la logique du facteur cognitif, qui substitue au secret une preuve d'intention résolue dans un canal éphémère ouvert par QR code dynamique à usage unique.
Documenter la posture. Les questionnaires de sécurité clients demandent désormais comment l'éditeur traite le rejeu d'identifiants. Une réponse précise est un argument commercial.
FAQ
Un CAPTCHA suffit-il à arrêter une campagne de rejeu ?
Il augmente le coût de l'attaque sans la rendre impossible, et il dégrade l'expérience et l'accessibilité. Il se justifie en escalade sur un trafic déjà qualifié de suspect, pas comme protection permanente sur tout le trafic.
Faut-il forcer la MFA sur tous les utilisateurs finaux ?
Sur les comptes à privilèges d'un tenant, oui : le risque de propagation le justifie. Sur les comptes standards, une exigence graduée selon la sensibilité de l'action donne un meilleur rapport entre protection et adoption.
Comment éviter que la protection anti-rejeu bloque des clients légitimes ?
En limitant par empreinte et par origine plutôt que par compte, et en prévoyant une voie de recours rapide. Un client bloqué à tort par une contre-mesure devient un ticket, puis un motif de départ.
L'éditeur est-il responsable d'une prise de contrôle par rejeu ?
Le service n'a pas fui, mais il a laissé rejouer. Les attentes contractuelles et réglementaires portent aujourd'hui sur la capacité à détecter et à limiter ce type de campagne, pas seulement sur l'absence de fuite.
Aller plus loin : le 4ᵉ facteur cognitif · AiTM chez les éditeurs SaaS · passkey face au credential stuffing · IAM et CIAM : ce qui change