Le brute force n'a pas disparu avec les politiques de verrouillage : il a changé de terrain. Il s'exerce désormais hors ligne, sur des empreintes dérobées, ou en surface fine avec le password spraying, qui teste un mot de passe plausible sur des milliers de comptes pour rester sous les seuils de blocage. Sa rentabilité repose sur trois conditions, et le polymorphisme fonctionnel en supprime une : la stabilité de la cible.
Trois formes, un même principe
| Forme | Où elle s'exécute | Ce qui la rend possible | Contre-mesure habituelle |
|---|---|---|---|
| En ligne classique | contre le service | absence de limitation de débit | verrouillage, temporisation |
| Password spraying | contre un annuaire entier | seuils calculés par compte, pas par campagne | détection transversale |
| Hors ligne | sur une base d'empreintes volée | l'empreinte est stable et rejouable | hachage lent, salage |
| Ciblé sur un facteur | contre un code court | espace de recherche réduit | limitation de tentatives |
La ligne « hors ligne » est la plus instructive. Une fois la base volée, l'attaquant n'a plus aucune limite de débit : il travaille chez lui, avec ses propres moyens de calcul, aussi longtemps qu'il le souhaite. Toutes les protections côté service — verrouillage, temporisation, alerte — sont devenues hors jeu.
Les trois conditions de rentabilité
Un brute force est rentable si, et seulement si :
- Il existe une valeur à retrouver. Un mot de passe, une empreinte, un code. Sans valeur cible, la recherche n'a pas d'objet.
- Un oracle permet de vérifier une hypothèse. L'attaquant doit pouvoir savoir s'il a trouvé, en ligne (le service répond) ou hors ligne (l'empreinte se recalcule).
- La cible ne bouge pas pendant la recherche. Une valeur qui changerait plus vite que le temps de recherche rendrait l'effort caduc.
Les défenses classiques agissent sur la deuxième condition — ralentir l'oracle — et un peu sur la première, en augmentant l'entropie. Elles ne touchent presque jamais la troisième.
Le polymorphisme fonctionnel : supprimer la cible stable
Le polymorphisme fonctionnel, associé au Moving Target Defense, fait varier la manière dont l'exécution se déroule. Combiné à une approche sans secret réutilisable, il agit sur les trois conditions à la fois :
- Condition 1 — la valeur. Une approche passwordless et IDless signifie qu'il n'existe ni mot de passe à retrouver ni identifiant à énumérer. Le facteur repose sur une méthode de résolution personnelle, jamais transmise, donc jamais présente dans une base à voler.
- Condition 2 — l'oracle. Une réponse ne vaut que pour le challenge en cours. Tester une hypothèse n'apprend rien de réutilisable pour le challenge suivant.
- Condition 3 — la stabilité. C'est l'apport propre du polymorphisme : la cible d'aujourd'hui n'est pas celle de demain, ce qui vise à rendre l'effort de recherche non capitalisable.
S'y ajoute, pour la partie cryptographique, l'usage de fonctions de hachage composées — plus de trente combinaisons — pensées notamment pour la résistance à moyen terme face à l'algorithme de Grover, qui divise par deux la sécurité effective des schémas symétriques.
Ce que cela change pour vos politiques
Deux conséquences pratiques, souvent contre-intuitives.
Le verrouillage de compte devient moins central. Il reste utile là où des mots de passe subsistent, mais il a toujours eu un effet secondaire désagréable : il offre un déni de service par verrouillage massif, et il pousse les utilisateurs vers des mots de passe faibles et mémorisables pour éviter les blocages.
L'énumération de comptes devient un sujet à part entière. Le password spraying commence par constituer une liste d'identifiants valides, souvent déduite d'une nomenclature d'entreprise prévisible. Supprimer l'identifiant permanent retire cette première étape, ce qui a plus d'effet que d'ajouter une règle de complexité.
Une politique de mots de passe reste nécessaire tant qu'il en existe. Mais l'effort marginal a davantage de rendement sur la réduction du nombre de secrets que sur leur durcissement.
Où porter l'effort en priorité
- Les comptes à privilèges, cible naturelle du spraying parce qu'ils ont un rendement élevé.
- Les interfaces exposées — accès distants, portails d'administration, interfaces techniques — où les tentatives passent souvent inaperçues.
- Les comptes de service, rarement soumis aux mêmes règles et rarement surveillés.
- Les parcours de récupération, qui contournent purement et simplement le facteur principal.
FAQ
Une politique de mots de passe longue et complexe ne suffit-elle pas ?
Elle augmente le coût du brute force, sans traiter la réutilisation ni le vol d'empreintes. Les identifiants volés, réutilisés ou partagés restent l'un des tout premiers vecteurs d'intrusion selon le Verizon DBIR — un mot de passe long qui a fuité reste un mot de passe qui a fuité.
Le brute force menace-t-il aussi les codes TOTP ?
Un code à six chiffres offre un espace de recherche limité, ce qui rend la limitation de tentatives indispensable côté service. Sans elle, l'attaque devient praticable dans la fenêtre de validité.
Le polymorphisme protège-t-il des bases d'empreintes volées ?
La meilleure protection reste de ne pas détenir de secret réutilisable. Une architecture décentralisée, sans donnée identifiante centralisée chez l'éditeur, supprime la base qui constituait la cible.
Faut-il conserver le verrouillage de compte ?
Oui, tant que des mots de passe existent, mais en le complétant par une détection transversale : une même tentative répétée sur des milliers de comptes ne déclenche aucun seuil individuel.
Aller plus loin : comprendre le facteur cognitif · le polymorphisme face aux zero-day · le mot de passe face au brute force · l'authentification sans identifiant