Dans l'industrie, le credential stuffing ne réussit pas parce que les mots de passe sont faibles, mais parce qu'il existe encore des portes qui n'acceptent qu'un mot de passe. Concentrateurs VPN hérités, applications métier anciennes, interfaces d'administration d'atelier, portails fournisseurs non fédérés : ces points d'entrée acceptent un couple identifiant / mot de passe et rien d'autre. Un attaquant qui rejoue des fuites publiques n'a pas besoin de contourner une MFA — il lui suffit de trouver l'endroit où elle n'existe pas.
La géographie du problème : là où la MFA n'est jamais arrivée
Une industrie de taille moyenne a généralement fait l'effort sur la messagerie et sur le fournisseur d'identité central. Ce qui reste exposé se répartit en quatre familles.
Les applications antérieures aux standards modernes. Elles ne parlent ni SAML ni OpenID Connect, et leur éditeur n'existe parfois plus. Les modifier est hors de portée ; les placer derrière un point d'entrée qui, lui, porte un facteur fort, est réaliste.
Les accès distants hérités. Un concentrateur VPN installé pour une population restreinte, jamais retiré, dont la liste d'utilisateurs a doublé au fil des années.
Les interfaces d'administration d'équipements. Superviseurs, passerelles, ponts série-Ethernet : elles n'ont jamais eu de mécanisme d'authentification autre que le mot de passe.
Les portails d'échange avec les partenaires. Chaque client ou donneur d'ordre impose le sien, avec son propre niveau d'exigence, et les mêmes personnes y réutilisent souvent les mêmes secrets.
La réutilisation entre sphère personnelle et professionnelle
Le vecteur dominant est humain : un opérateur, un technicien ou un acheteur emploie sur un portail professionnel un secret déjà utilisé ailleurs. Les identifiants volés, réutilisés ou partagés comptent parmi les tout premiers vecteurs d'intrusion recensés par le Verizon DBIR, et l'industrie ne fait pas exception.
Ce mécanisme est particulièrement difficile à traiter par la sensibilisation seule, parce qu'il ne suppose aucune erreur au travail : la fuite s'est produite ailleurs, dans un contexte personnel, et l'entreprise n'en a aucune visibilité.
| Palier de traitement | Population concernée | Effort | Effet sur le rejeu |
|---|---|---|---|
| Filtrage des secrets déjà compromis | Tous les comptes | Faible | Élevé, immédiat |
| Fédération des applications compatibles | Applications récentes | Moyen | Élevé |
| Portail d'accès devant le legacy | Applications anciennes | Moyen | Élevé |
| Facteur lié à l'origine sur les privilèges | Administrateurs, achats | Moyen | Très élevé |
| Nominativation des comptes partagés | Ateliers, astreintes | Élevé, organisationnel | Élevé |
| Preuve d'intention sur les gestes critiques | Achats, ingénierie, maintenance | Moyen | Complémentaire |
L'ordre proposé n'est pas théorique : les deux premières lignes produisent un effet mesurable en quelques semaines, sans dépendre d'un projet applicatif.
Ce que l'attaquant fait des comptes obtenus
En industrie, un compte rejoué sert rarement à un vol direct. Il sert à entrer. Une fois dans le réseau, l'attaquant cherche la propriété industrielle, les coordonnées bancaires fournisseurs, ou une position permettant un déploiement de rançongiciel.
Deux préjudices dominent. Le premier est la fraude au changement de RIB fournisseur, préparée par la lecture des échanges d'achats. Le second est l'interruption de production, dont le coût se compte en journées d'arrêt et en pénalités contractuelles.
Ce lien entre compte rejoué et arrêt de production explique pourquoi le sujet dépasse la direction informatique : il relève du plan de continuité d'activité autant que de la politique de sécurité.
Contre-mesures spécifiques au contexte industriel
Inventorier les points d'authentification, pas seulement les applications. La question utile est « combien d'endroits acceptent un mot de passe seul ? ». La réponse est presque toujours plus élevée que prévu.
Refuser les secrets déjà compromis. Cette mesure ne demande aucun changement de parcours utilisateur et retire la matière première de l'attaque.
Traiter les comptes partagés comme une dette. Un compte d'atelier utilisé par une équipe entière ne peut être ni tracé, ni révoqué, ni protégé par un facteur personnel. Sa suppression est un projet organisationnel, pas technique.
Contractualiser avec les partenaires. Le niveau d'authentification exigé pour accéder aux plateformes d'échange doit figurer dans les conditions de référencement, avec un périmètre réduit pour ceux qui ne peuvent pas s'y conformer.
Ancrer les gestes coûteux. Validation d'un ordre d'achat, modification de coordonnées bancaires, publication d'une révision de plan, ouverture d'un accès de maintenance : ces actions gagnent à exiger une preuve d'intention distincte du simple fait d'être connecté. Le facteur cognitif fournit cette preuve sans identifiant ni mot de passe, ce qui la rend structurellement insensible au rejeu de fuites, et se déploie en overlay d'un dispositif existant.
FAQ
Comment protéger une application qui n'accepte qu'un mot de passe ?
En la plaçant derrière un point d'entrée qui porte l'authentification forte, et en restreignant les origines réseau autorisées. Modifier l'application est souvent impossible ou disproportionné.
Le credential stuffing est-il vraiment un risque pour un site de production ?
Oui, mais indirectement. Il fournit une entrée dans le réseau bureautique ou dans un accès distant. La progression vers les systèmes industriels emprunte ensuite les chemins légitimes.
Faut-il forcer un changement de mot de passe régulier ?
La rotation systématique produit des secrets prévisibles et une lassitude contre-productive. Mieux vaut interdire les secrets compromis, imposer une longueur suffisante, et forcer le changement uniquement en cas de compromission avérée.
Que faire des comptes de sous-traitants inactifs depuis des mois ?
Les désactiver par défaut et les réactiver à la demande sur une fenêtre définie. Un compte partenaire oublié est l'une des cibles les plus rentables d'une campagne de rejeu.
Aller plus loin : le 4ᵉ facteur cognitif · AiTM dans l'industrie et les OIV · NIS2 pour l'industrie · migrer vers le passwordless