Contre le rejeu, le SMS-OTP fait partiellement son travail : un code à usage unique et à durée de vie limitée ne peut pas être réutilisé plus tard, contrairement à un mot de passe. La protection s'arrête toutefois à trois endroits précis : les défauts d'implémentation côté serveur, l'absence de lien entre le code et l'opération validée, et le fait que le véritable objet rejouable n'est pas le code mais la session qui en résulte.
Ce que « rejeu » signifie exactement ici
Le terme recouvre trois situations différentes, qu'il vaut mieux distinguer avant de conclure.
Le rejeu du secret. Réutiliser la même valeur pour une seconde authentification. C'est ce que le caractère à usage unique est censé empêcher.
Le rejeu dans la fenêtre. Utiliser le code pendant sa période de validité, pour une autre tentative que celle qui l'a déclenché. C'est là que les implémentations pèchent.
Le rejeu de la conséquence. Réutiliser le jeton de session obtenu grâce au code. Aucune propriété du code ne protège de cela.
Un mot de passe est vulnérable aux trois. Un OTP correctement implémenté ne bloque que les deux premiers, et seulement s'il est bien conçu.
Les défauts d'implémentation qui rouvrent le rejeu
| Défaut | Conséquence | Correction attendue |
|---|---|---|
| Code non invalidé après consommation | Réutilisation possible dans la fenêtre restante | Invalidation immédiate à la première acceptation |
| Fenêtre de validité longue | Fenêtre d'exploitation confortable | Durée alignée sur le délai de livraison réel, sans excès |
| Renvoi produisant le même code | Plusieurs canaux d'interception pour une valeur unique | Nouveau code à chaque envoi, ancien invalidé |
| Absence de plafond de tentatives | Recherche exhaustive sur un code court | Verrouillage progressif par compte et par origine |
| Code accepté indifféremment par plusieurs parcours | Un code émis pour une connexion valide une opération | Cloisonnement par contexte d'émission |
| Aucun lien avec l'opération | Le code vaut pour n'importe quelle transaction | Lien dynamique montant et bénéficiaire |
La dernière ligne est la plus structurante. Un code qui certifie « quelqu'un détient ce téléphone » ne certifie pas « cette personne autorise ce virement de 42 000 euros vers ce bénéficiaire ». Sans lien avec l'opération, le code devient un jeton générique, réutilisable par l'attaquant pour valider une autre action déclenchée simultanément.
Le lien dynamique : la réponse réglementaire au rejeu
La directive DSP2 ((UE) 2015/2366) l'a formalisé pour les paiements : l'authentification forte du client doit combiner deux facteurs de catégories distinctes et établir un lien dynamique entre l'authentification, le montant et le bénéficiaire. Toute modification de l'un ou de l'autre invalide l'authentification.
Traduit en pratique, cela signifie qu'un message contenant seulement « votre code est 481902 » ne satisfait pas l'esprit de l'exigence. Le message doit porter le contexte de l'opération, et le serveur doit vérifier que le code présenté correspond bien à cette opération.
Cette exigence a une portée qui dépasse le secteur des paiements. Le même raisonnement s'applique à un changement de coordonnées bancaires fournisseur, à une création de compte à privilèges ou à la signature d'un acte : lier la preuve à l'action est ce qui rend le rejeu inopérant.
Le rejeu qui reste possible malgré tout
Même parfaitement implémenté et lié à l'opération, un SMS-OTP laisse deux angles ouverts.
Le relais en temps réel. Un proxy inverse n'a pas besoin de rejouer : il utilise le code immédiatement, dans le cadre de l'opération légitime affichée à la victime. Le lien dynamique protège contre la substitution d'opération, pas contre la capture de session qui suit.
Le jeton émis ensuite. Une fois l'authentification acceptée, le service délivre une session. Ce jeton, lui, est rejouable jusqu'à expiration ou révocation. C'est la limite commune à toutes les méthodes qui traitent l'authentification comme un événement d'entrée.
Deux orientations ferment ces angles : la variation continue des paramètres d'exécution (Moving Target Defense), qui prive le rejeu d'une cible stable, et la preuve d'intention au moment de l'action, qui rend la session insuffisante pour agir. C'est la logique de l'authentification cognitive, où le challenge est résolu dans un canal éphémère, sans secret réutilisable.
Points de contrôle pour un audit
- Vérifier que le code est invalidé dès la première acceptation, y compris en cas d'échec partiel du parcours.
- Mesurer la durée de vie réelle et le comportement du renvoi.
- Tester la substitution d'opération : le code émis pour une action A est-il accepté pour une action B ?
- Contrôler l'existence d'un plafond de tentatives par compte, par origine et par période.
- Vérifier que les journaux permettent de reconstituer quelle opération a été validée par quel code.
- Documenter la procédure de révocation de session applicable après une authentification suspecte.
FAQ
Un code à six chiffres est-il trop court ?
Sa longueur suffit si, et seulement si, le serveur limite strictement les tentatives et invalide le code après usage. Sans ces contrôles, la brièveté du code devient exploitable ; avec eux, ce n'est pas le paramètre déterminant.
Le lien dynamique est-il obligatoire hors paiement ?
Il n'est imposé que dans le cadre de la DSP2 pour les opérations de paiement électronique. Le principe reste néanmoins la meilleure pratique disponible pour toute opération sensible, quel que soit le secteur.
Un attaquant peut-il rejouer un code intercepté sur le réseau ?
Le SMS transite par des infrastructures d'opérateurs qui échappent au contrôle de l'entreprise, ce qui constitue une exposition réelle. Mais le scénario le plus fréquent reste beaucoup plus simple : obtenir le code de la victime elle-même.
Que vérifier après une suspicion de rejeu ?
La correspondance entre chaque code émis et l'opération effectivement validée, l'existence de deux acceptations pour un même code, et surtout les sessions ouvertes dans la même fenêtre temporelle, qui constituent le véritable accès résiduel.
Aller plus loin : le 4ᵉ facteur cognitif · Moving Target Defense contre le rejeu · DSP2 et authentification · vol de session : ce qui reste possible