Fenêtres de suppression des OTP par SMS : réduire les renvois en double sans bloquer les utilisateurs légitimes

Le problème opérationnel : les renvois ne relèvent pas seulement de l’UX

Lorsqu’une personne demande plusieurs fois un code OTP par SMS, le système peut générer des codes simultanés, augmenter le coût de la messagerie, créer une confusion sur le code à saisir et élargir la surface d’abus. Cela peut également accroître les sollicitations du support si l’utilisateur reçoit des messages retardés ou si un code précédent cesse de fonctionner sans explication claire.

Toutefois, supprimer rigidement chaque demande répétée peut aussi empêcher une authentification légitime. Le retard peut provenir du réseau, du fournisseur de messagerie, du terminal ou de la connectivité de l’utilisateur. En outre, certains utilisateurs ne peuvent pas toujours compter sur une couverture mobile et doivent disposer de méthodes d’authentification alternatives autorisées.

La fenêtre de suppression des OTP par SMS est un contrôle opérationnel qui décide si une nouvelle demande doit être acceptée, différée ou ne doit pas générer un autre SMS. Elle ne remplace pas les contrôles de sécurité de l’OTP : elle doit fonctionner avec la durée de validité limitée du secret, l’acceptation à usage unique, la limitation des tentatives de vérification et l’évaluation des risques.

• Objectif de sécurité : limiter les abus de demandes et de tentatives de vérification.
• Objectif opérationnel : éviter les messages en double et les états incohérents.
• Objectif d’expérience : informer du délai d’attente sans révéler l’existence d’un compte ou d’un numéro.
• Objectif d’accessibilité : proposer des méthodes alternatives lorsque le SMS ne peut pas être utilisé.

Ce qu’une fenêtre de suppression régit

Une fenêtre de suppression ne doit pas répondre uniquement à la question : « Combien de temps s’est écoulé depuis le dernier clic ? » Elle doit régir une décision complète : créer une nouvelle demande, réutiliser une demande encore valide, différer l’envoi, annuler une tentative en attente ou orienter l’utilisateur vers une alternative autorisée.

La décision doit être déterministe côté serveur. L’interface peut afficher un compte à rebours, mais elle ne doit pas déterminer à quel moment un renvoi est autorisé. Le serveur conserve l’état de la demande, évalue les limites et le risque, émet le code et décide quel secret peut être vérifié.

Il est utile de définir explicitement le comportement des codes précédents. Une politique courante consiste à invalider les codes antérieurs lorsqu’un nouveau code est émis pour la même finalité et la même demande d’authentification. Si cette politique est retenue, elle doit être communiquée à l’utilisateur et appliquée de manière atomique afin d’éviter que deux codes restent valides à cause d’une condition de concurrence.

• Autoriser : aucune demande encore valide ne doit être supprimée et les limites permettent l’envoi.
• Différer : la demande est légitime, mais le délai avant renvoi est toujours actif.
• Supprimer : une duplication est détectée, une opération équivalente est déjà en cours ou une restriction applicable est dépassée.
• Escalader ou changer de canal : le risque, l’accessibilité ou une défaillance technique confirmée justifient un parcours alternatif autorisé.

Distinguer les trois temporisateurs essentiels

La validité du code, le délai avant renvoi et l’expiration de la demande sont trois temporisateurs distincts. Les confondre entraîne généralement deux erreurs : conserver un code acceptable plus longtemps que nécessaire ou refuser un renvoi légitime parce que le délai d’attente est confondu avec la validité cryptographique.

La validité du code définit jusqu’à quand le vérificateur peut accepter le secret. Le NIST indique que l’authentification hors bande doit être achevée dans un délai de 10 minutes et que le même secret ne doit être accepté qu’une seule fois pendant sa période de validité. Une implémentation peut choisir une validité plus courte si son analyse de risque et son expérience utilisateur le justifient.

Le délai avant renvoi définit combien de temps la personne doit attendre avant de demander un autre SMS. Il s’agit d’une décision opérationnelle distincte : il doit réduire les clics répétés et le trafic en double, sans être considéré comme une preuve que le premier SMS n’arrivera pas. L’expiration de la demande détermine quand la transaction d’authentification est clôturée et qu’un nouveau flux doit être initié.

• Validité du code : contrôle l’acceptation du secret et sa résistance à la répétition.
• Délai avant renvoi : contrôle la fréquence des nouveaux envois.
• Expiration de la demande : ferme le contexte transactionnel et évite les états indéfinis.
• Limite de tentatives de vérification : contrôle les essais échoués et ne doit pas être réinitialisée lors de l’émission d’un autre code.

Modèle d’états pour une demande OTP

Modélisez la demande OTP comme une transaction interne dotée d’un identifiant unique. Les états du fournisseur de messagerie doivent être associés à cette transaction, mais ils ne doivent pas contrôler seuls la validité du code ni le résultat de l’authentification.

Un modèle minimal peut inclure les états créée, acceptée, envoyée, état final signalé, vérifiée, expirée et annulée. L’état « état final signalé » indique qu’une mise à jour terminale a été reçue du système de messagerie, mais n’affirme pas que l’utilisateur a vu, lu ou utilisé le SMS.

Les transitions doivent être contrôlées par le serveur et idempotentes. Par exemple, une vérification réussie doit empêcher toute réutilisation du secret, même si un callback de livraison retardé arrive ensuite. De même, une mise à jour externe reçue dans le désordre ne doit pas rouvrir une demande expirée, annulée ou déjà vérifiée.

• Créée : le contexte d’authentification existe, mais l’envoi n’a pas encore été accepté.
• Acceptée : les validations internes ont été réussies et la décision de lancer l’envoi a été prise.
• Envoyée : le système a enregistré l’émission vers la connectivité de messagerie.
• État final signalé : un état terminal externe a été reçu, dont la sémantique doit être conservée sans surinterprétation.
• Vérifiée : le secret valide a été renvoyé et accepté une seule fois.
• Expirée ou annulée : la demande ne peut plus aboutir à une authentification réussie.

Éléments de preuve pour décider d’un renvoi et limites des DLR

L’élément de preuve le plus solide pour l’authentification est la vérification réussie du secret pendant sa période de validité. Un événement de transport ne remplace pas la réponse explicite de l’utilisateur et ne prouve pas que le code a été reçu, lu ou saisi sur le terminal.

Pour décider d’un renvoi, classez les éléments de preuve selon leur fonction. Les événements internes indiquent s’il existe déjà une demande active, si un code reste valide, si une vérification a eu lieu ou si des limites ont été atteintes. La réponse d’envoi permet de savoir si le système de messagerie a accepté ou rejeté l’opération selon son interface. Les DLR peuvent fournir des informations sur l’état de livraison signalé, mais leur interprétation dépend de la sémantique disponible dans la chaîne de messagerie.

Un DLR signalé comme livré ne doit pas être considéré comme une confirmation indépendante de réception physique, de lecture ou de possession légitime du terminal. Un DLR en attente ne prouve pas non plus une défaillance. La politique de suppression doit éviter à la fois le renvoi immédiat en l’absence de DLR et le blocage automatique du fait qu’un DLR a été signalé comme livré.

• Utilisez l’état interne pour conserver l’autorité sur la décision.
• Conservez la réponse d’envoi et son identifiant de corrélation.
• Stockez le DLR d’origine, son heure de réception et son lien avec le message.
• Ne transformez pas un DLR en preuve de lecture, d’identité, de consentement ou de réussite de l’authentification.
• Validez l’OTP côté serveur même si une livraison a été signalée.

Règles pratiques selon les scénarios

Lors de la première demande, validez et normalisez la destination conformément au plan de numérotation international applicable, créez la transaction, générez le secret de courte durée et consignez l’événement avant de lancer l’envoi. Le résultat doit être associé à des identifiants de demande, de code et de message, sans enregistrer le secret en clair.

En cas de renvoi précoce, si une demande active existe et que le délai avant renvoi n’est pas écoulé, ne générez pas automatiquement un autre code. Renvoyez une réponse générique indiquant le délai d’attente applicable et maintenez la possibilité de saisir le code actuel. Si un renvoi est autorisé à l’issue du délai, appliquez de manière atomique la politique retenue pour le code précédent.

Lorsque le code a expiré, clôturez la demande précédente et créez-en une nouvelle uniquement si les limites et les signaux de risque le permettent. Si la plateforme confirme une défaillance technique avant que l’envoi ait été accepté, une exception de nouvelle tentative peut être définie ; cette exception doit être tracée et ne doit pas devenir un mécanisme illimité de génération.

En cas de changement de canal, ne présumez pas que le SMS convient à toutes les situations. L’utilisation du réseau téléphonique commuté public pour l’authentification hors bande comporte des risques qui doivent être évalués. Tenez compte des signaux de risque disponibles, tels que les changements d’appareil, de SIM ou de portabilité, et orientez vers un authentificateur alternatif autorisé lorsque la politique l’exige.

• Première demande : créer le contexte, consigner l’événement, envoyer et activer les temporisateurs.
• Renvoi pendant le délai de refroidissement : conserver le code valide et afficher le temps d’attente.
• Code expiré : clôturer le contexte précédent avant d’en émettre un nouveau.
• Défaillance technique confirmée : appliquer une exception limitée, idempotente et auditable.
• Changement de canal : préserver le contexte de risque et ne pas affaiblir les contrôles de vérification.

DLR en attente, rejetés ou livrés : un traitement prudent

Un DLR en attente indique qu’aucune mise à jour terminale n’est encore disponible pour cette opération. Ce n’est pas une raison suffisante pour émettre immédiatement un autre SMS. Maintenez la fenêtre de refroidissement et permettez à l’utilisateur de saisir le code tant qu’il reste valide.

Un rejet ou un échec signalé peut justifier une politique de nouvelle tentative contrôlée s’il est confirmé que l’envoi n’a pas été accepté ou n’a pas progressé selon les critères internes définis. La nouvelle tentative doit néanmoins être soumise à des limites et à une clé d’idempotence afin que les tentatives réseau ne créent pas plusieurs messages.

Si la livraison est signalée, maintenez la règle de non-équivalence : le système peut enregistrer cet état à des fins d’analyse opérationnelle, mais il ne doit pas bloquer toute alternative ni conclure que l’utilisateur dispose déjà du code. L’authentification n’est terminée que lorsque le vérificateur accepte le secret valide renvoyé par la personne.

• En attente : patienter, conserver la demande et ne pas déduire un échec.
• Rejeté : vérifier la signification technique de l’événement avant toute nouvelle tentative.
• Livré : enregistrer comme signal de transport, non comme preuve de lecture ou d’authentification.
• Reçu dans le désordre : conserver l’événement à des fins de diagnostic sans faire régresser l’état interne.
• Dupliqué : accepter le callback de manière idempotente et éviter les effets répétés.

Contrôles contre les abus sans bloquer les utilisateurs légitimes

La suppression des renvois doit être associée à des limites de demandes et de vérifications. Les OTP courts nécessitent de limiter les tentatives de vérification échouées afin de réduire la devinette en ligne. L’émission d’un nouveau code ne doit pas réinitialiser ce compteur d’échecs.

Ne fondez pas le contrôle uniquement sur une adresse IP. OWASP recommande d’associer les compteurs d’échecs au compte et d’utiliser l’IP, l’appareil, la localisation, l’heure et le comportement comme signaux complémentaires. Pour les demandes d’OTP, le numéro de destination, le compte, la session et l’appareil peuvent apporter des contextes différents ; aucun ne doit être considéré à lui seul comme une preuve d’identité.

Appliquez des mesures progressives plutôt qu’une réponse binaire unique. Le NIST prévoit que des délais croissants, la détection des bots et l’évaluation adaptative peuvent compléter la limitation. Examinez les faux positifs : les voyages, les réseaux partagés, les nouveaux appareils, une couverture limitée et les besoins d’accessibilité peuvent expliquer des comportements légitimes.

• Limites par compte : protègent le flux d’authentification associé.
• Limites par numéro : réduisent la pression d’envoi vers une destination précise.
• Limites par session et appareil : aident à détecter la répétition automatisée dans le même contexte.
• IP et autres signaux : apportent du contexte, mais ne doivent pas constituer le seul critère.
• Escalade progressive : attente, défi supplémentaire, alternative autorisée ou examen, selon le risque.