Une attaque par rejeu consiste à capturer un échange valide puis à le retransmettre pour se faire passer pour l'émetteur légitime. Elle ne suppose ni faille cryptographique ni compromission de compte : il suffit que l'élément capté conserve une valeur au-delà de l'instant où il a été produit. Le Moving Target Defense attaque cette hypothèse en faisant varier en permanence les paramètres d'exécution, de sorte qu'un enregistrement ne corresponde plus à rien.
Ce que le rejeu exige pour fonctionner
Trois conditions doivent être réunies, et il suffit d'en casser une.
- Une position d'écoute : réseau non maîtrisé, poste compromis, proxy interposé, journal mal protégé.
- Un élément qui garde sa valeur : un code, un jeton, une signature, une réponse d'appel d'interface.
- Une fenêtre d'acceptation : un intervalle pendant lequel le service accepte encore cet élément.
La deuxième et la troisième sont des choix de conception. C'est là que se situe la marge de manœuvre réelle, bien plus que dans la tentative d'éliminer toute écoute possible.
Où se situent les méthodes courantes
| Méthode | Élément capturable | Fenêtre d'acceptation | Rejeu praticable |
|---|---|---|---|
| Mot de passe | le mot de passe lui-même | jusqu'au changement | oui, durablement |
| SMS-OTP | le code reçu | quelques minutes | oui ; le NIST SP 800-63B le classe « restricted » |
| TOTP | le code affiché | l'intervalle courant, souvent avec tolérance | oui, dans la fenêtre |
| Notification push | l'approbation | l'instant de la demande | partiellement, par déclenchement forcé |
| FIDO2 / WebAuthn | signature liée à l'origine | inexploitable hors du domaine | non |
| Cookie de session | le jeton émis | durée de vie de la session | oui, et c'est le cas le plus courant |
| Challenge cognitif | un résultat lié à un challenge unique | l'échange en cours | sans objet |
Le tableau met en évidence une confusion fréquente : on protège soigneusement l'authentification contre le rejeu, puis on émet un jeton de session à longue durée de vie, qui est exactement l'objet le plus rejouable de la chaîne.
Le principe du Moving Target Defense
Le Moving Target Defense renverse une hypothèse implicite de la sécurité informatique : celle d'un système figé qu'il faut protéger. Il consiste à faire varier la configuration et les paramètres d'exécution de manière continue, afin que la connaissance acquise par un observateur se périme avant de pouvoir servir.
Appliqué à une chaîne d'authentification, cela se traduit par trois effets sur le rejeu :
- Ce qui a été observé ne correspond plus. L'élément capté est indexé sur un état d'exécution qui n'existe plus au moment où l'attaquant tenterait de le rejouer.
- L'accumulation ne paie pas. Répéter l'écoute ne construit pas un modèle stable, puisque la cible change entre deux observations.
- Le coût de l'attaque devient continu. L'attaquant ne peut plus investir une fois pour exploiter longtemps ; il doit maintenir sa présence, ce qui augmente sa visibilité.
Chez HIAsecure, ce principe s'accompagne du polymorphisme fonctionnel et d'un canal éphémère ouvert par un QR code dynamique à usage unique. L'objectif visé est cumulatif : supprimer la valeur de ce qui circule, puis empêcher qu'une observation répétée compense cette suppression.
Ce que cela implique côté exploitation
Une surface mouvante a des conséquences opérationnelles qu'il vaut mieux anticiper.
- La journalisation doit rester exploitable. Faire varier l'exécution ne dispense pas de produire des traces cohérentes pour l'investigation ; c'est une exigence explicite des cadres NIS2 et DORA.
- La supervision doit distinguer variation légitime et anomalie. Une surveillance calibrée sur une empreinte figée génère du bruit face à une exécution mouvante.
- La révocation de session reste indispensable. Le rejeu le plus courant portant sur les jetons, la capacité à les invalider vite conditionne toute la chaîne.
Trois vérifications à mener chez vous
- Quels parcours acceptent encore un code transmissible ? Ce sont les candidats immédiats au remplacement, en commençant par les populations les plus ciblées.
- Quelle est la durée de vie réelle des sessions sensibles ? Souvent plus longue que ce que la politique affiche, du fait des renouvellements silencieux.
- Une opération à fort impact peut-elle s'exécuter sans nouvelle preuve ? Si oui, un jeton rejoué suffit à la déclencher.
FAQ
L'horodatage ne suffit-il pas à empêcher le rejeu ?
Il réduit la fenêtre sans la fermer. Les tolérances de synchronisation et les délais réseau imposent un intervalle d'acceptation, et un relais automatisé travaille dans un temps très inférieur à cet intervalle.
Le TOTP protège-t-il du rejeu ?
Partiellement. Le code expire, mais il reste valide assez longtemps pour être relayé en direct, et beaucoup d'implémentations tolèrent l'intervalle précédent. Le TOTP protège surtout contre la réutilisation d'un mot de passe volé.
Le Moving Target Defense remplace-t-il la cryptographie ?
Non, il la complète. La cryptographie protège le contenu d'un échange ; l'exécution mouvante vise à empêcher qu'une observation répétée du système devienne exploitable.
Comment vérifier qu'un fournisseur traite réellement le rejeu ?
En lui demandant ce qui reste exploitable après capture complète d'un échange, et pendant combien de temps. Une réponse précise sur la durée de vie des jetons et sur ce qui est validé au moment de l'action est plus informative qu'une liste de fonctionnalités.
Aller plus loin : le facteur cognitif en détail · le Moving Target Defense face au vol de session · le SMS-OTP face au rejeu · définition du rejeu