Limitation de débit des OTP par SMS : limites par utilisateur, numéro, IP et appareil sans nuire à l’authentification

Pourquoi la limitation de débit des OTP est une politique opérationnelle, et pas seulement un contrôle technique

La limitation de débit des OTP par SMS protège plusieurs actifs à la fois : le flux d’authentification, le budget de messagerie, la capacité opérationnelle et l’expérience de la personne qui tente d’accéder légitimement au service. Une politique trop permissive peut faciliter les demandes automatisées, saturer le canal SMS du destinataire et générer du trafic artificiel. Une politique trop stricte peut empêcher des accès légitimes ou devenir un vecteur de déni de service contre des comptes précis.

L’objectif n’est pas de bloquer les SMS de façon indiscriminée. Il consiste à décider, de manière mesurable et révisable, quand autoriser une demande, quand introduire une attente ou une friction supplémentaire et quand restreindre temporairement une action à risque. L’unité de contrôle doit correspondre à l’action protégée et au risque observé.

• Distinguer l’abus des demandes de l’échec de saisie du code.
• Éviter qu’une restriction fondée sur un seul signal, comme l’IP, détermine à elle seule le résultat.
• Mesurer l’effet de chaque limite sur la sécurité, la conversion, les renvois et le coût.
• Maintenir un parcours de récupération autorisé pour les personnes qui ne peuvent pas terminer le flux habituel.

Ce qu’il faut protéger dans un flux OTP par SMS

Un flux OTP comprend des actions distinctes, qui ne doivent pas nécessairement partager le même quota. Au minimum, il est conseillé de traiter séparément la demande initiale de code, le renvoi, la validation du code et le passage à un canal alternatif ou de récupération. Chaque action présente une surface d’abus différente.

La validation du code exige une protection particulièrement rigoureuse. Lorsque le secret d’authentification est court, NIST impose une limite effective des tentatives consécutives échouées par compte et précise que l’émission d’un nouveau code ne doit pas réinitialiser ce compteur. Le code doit être à usage unique et le processus hors bande n’est plus valide s’il n’est pas achevé dans les dix minutes.

La demande ou le renvoi ne doivent pas, à eux seuls, modifier l’état d’un compte. Une requête répétée peut justifier une attente, une vérification supplémentaire ou une restriction temporaire de l’action, mais ne doit pas entraîner de changement sensible tant qu’un secret valide n’a pas été présenté.

• Demande initiale : protège contre l’automatisation et la génération de trafic SMS.
• Renvoi : évite les doublons, la fatigue du destinataire et la pression artificielle sur le transport.
• Validation : limite la devinette du code et doit conserver le compteur d’échecs même lorsqu’un nouveau code est émis.
• Changement de canal ou récupération : exige des règles propres et une évaluation du risque proportionnée.

Limiter selon plusieurs entités, pas seulement selon l’adresse IP

Une politique fondée uniquement sur l’IP est insuffisante. Un attaquant peut répartir ses tentatives sur plusieurs adresses, tandis que des utilisateurs légitimes peuvent partager une même sortie réseau. OWASP recommande d’associer le compteur d’échecs au compte plutôt que de dépendre exclusivement de l’IP.

La pratique la plus utile consiste à combiner plusieurs dimensions. Le compte ou l’identité de connexion contribue à protéger le processus d’authentification ; le numéro MSISDN contrôle la destination du SMS ; l’IP apporte un contexte d’origine ; l’appareil, la session et la campagne ou l’application permettent de détecter une concentration. Aucun signal ne doit être interprété seul comme une preuve concluante.

Avant d’appliquer des quotas par numéro, normalisez la destination de manière cohérente selon un plan de numérotation international, tel qu’E.164. Sans normalisation, différentes représentations d’un même numéro peuvent fragmenter les compteurs ou produire des décisions incohérentes.

• Compte : essentiel pour limiter les échecs de validation consécutifs et protéger contre la force brute distribuée.
• MSISDN normalisé : utile pour contrôler les demandes et renvois destinés au même destinataire.
• IP : signal complémentaire permettant de détecter le volume, l’automatisation ou la concentration, mais pas l’identité de l’utilisateur.
• Appareil : apporte du contexte, mais doit être utilisé de manière proportionnée car il peut être partagé.
• Session : permet de relier les demandes et validations à un flux précis.
• Campagne ou application : aide à isoler les problèmes et à éviter qu’une intégration affecte les autres.

Comment choisir les fenêtres, les quotas et le délai de refroidissement

Il n’existe pas de quota universel vérifiable qui convienne à tous les services. Les seuils doivent découler du risque lié au cas d’usage, de la population attendue, de la tolérance à la fraude, de la capacité du service et de l’impact du blocage d’une personne légitime. Ils doivent être documentés et réexaminés à partir de vos propres données.

Une fenêtre fixe est facile à expliquer et à auditer, mais elle peut concentrer les demandes à l’approche de ses limites. Une fenêtre glissante offre une lecture plus continue du comportement récent, bien qu’elle exige une mise en œuvre et une observabilité plus rigoureuses. Un délai de refroidissement progressif réduit les répétitions immédiates sans imposer d’emblée une interdiction longue.

OWASP identifie trois éléments qui doivent être explicites : le nombre d’échecs qui déclenche la restriction, la période durant laquelle ils sont comptés et la durée de la restriction. OWASP décrit également le verrouillage exponentiel, pour lequel l’attente est d’abord courte puis augmente après des échecs successifs.

• Utilisez des fenêtres simples lorsque l’explicabilité opérationnelle et l’audit sont prioritaires.
• Utilisez des fenêtres glissantes lorsqu’il est important d’éviter les pics artificiels autour d’une réinitialisation temporelle.
• Appliquez un délai de refroidissement progressif aux actions répétitives avant de recourir à des blocages étendus.
• Documentez pour chaque règle : entité, action, seuil, fenêtre, durée, exception autorisée, responsable et condition de réversibilité.

Dissocier demande, renvoi et validation évite les contrôles contradictoires

La demande initiale et le renvoi consomment de la capacité de messagerie ; la validation consomme de la capacité de vérification et fait face au risque de devinette. Un compteur unique pour l’ensemble du flux mélange les causes et complique l’analyse des incidents.

Une implémentation prudente peut conserver un état de défi par session ou transaction : destination normalisée, compte s’il existe dans le flux, identifiant de demande, heure d’émission, expiration, état d’utilisation, compteur des validations échouées et références pseudonymisées aux signaux de risque. Le secret OTP ne doit pas être enregistré en clair.

L’idempotence est également importante. Si le client répète une demande en raison d’une réponse perdue ou d’une condition réseau, le service doit pouvoir reconnaître cette répétition dans un contexte contrôlé plutôt que de générer inutilement plusieurs messages. Cette décision réduit les doublons et rend le comptage des demandes plus fiable.

• Ne réinitialisez pas les échecs de validation lors de la génération d’un nouveau code.
• Marquez le code comme consommé après une utilisation valide afin d’empêcher sa réutilisation.
• Indiquez clairement à l’utilisateur quand il peut demander un nouvel envoi, sans révéler d’informations sur le compte.
• Concevez des tentatives techniques idempotentes pour ne pas les confondre avec de nouvelles demandes humaines.
• Isolez les files d’envoi de la logique d’autorisation : accepter une demande ne revient pas à confirmer l’authentification.

Réponses sûres et friction progressive

La réponse d’un endpoint OTP doit rester neutre quant à l’existence, à l’état et à un éventuel blocage d’un compte. OWASP recommande des messages cohérents et une temporisation uniforme afin de réduire l’énumération au moyen de différences de contenu ou de temps.

Lorsqu’un signal de risque augmente, il est préférable d’appliquer une friction progressive plutôt qu’un blocage général. Par exemple, une attente visible avant le renvoi, une vérification supplémentaire contre l’automatisation ou une revue du risque peuvent constituer des mesures proportionnées. Un CAPTCHA peut servir de défense en profondeur et être introduit après quelques échecs, pas nécessairement dès la première tentative.

Les restrictions doivent empêcher les abus sans permettre à un tiers d’exclure des utilisateurs légitimes. Il n’est donc pas souhaitable d’appliquer une suspension de compte étendue uniquement parce que quelqu’un a demandé des codes à répétition pour cette destination.

• Utilisez des messages tels que : « Si le flux est valide, vous recevrez des instructions ou pourrez continuer à la fin du délai d’attente. »
• Affichez un compte à rebours de renvoi lié à la transaction, et non des informations indiquant si un compte existe.
• Augmentez la friction selon la répétition, la vitesse et la concentration des signaux, et non à partir d’une seule observation isolée.
• Réservez les restrictions à plus fort impact aux risques corroborés et pour une durée définie.
• Proposez une récupération autorisée lorsque le canal habituel n’est pas viable.

Signaux justifiant une revue ou un renforcement des contrôles

Les signaux de risque servent à prioriser les revues et à ajuster les contrôles ; ils ne constituent pas à eux seuls une identité ou une preuve de fraude. OWASP recommande de considérer comme non fiables les données reçues depuis les clients, les appareils, les réseaux ou les services externes, car elles peuvent être absentes, répétées, modifiées ou falsifiées.

Recherchez les schémas de concentration et de répétition : de nombreuses demandes pour une même destination, une activité rapide depuis une source, des séquences de renvoi sans validation, des échecs persistants du code ou un volume anormal au sein d’une même application. Dans les canaux RTC, NIST recommande d’évaluer des indicateurs tels qu’un changement d’appareil, un changement de SIM, la portabilité du numéro ou tout autre comportement anormal avant d’envoyer le secret.

L’appareil exige un traitement particulièrement prudent. Il peut fournir un signal utile face à des abus à grande échelle, mais les appareils sont également partagés. Ne transformez pas une association d’appareil en une interdiction automatique d’accès pour plusieurs utilisateurs légitimes.

• Concentration : répétition sur un compte, un numéro, une session ou une application.
• Vitesse : cadence incompatible avec l’utilisation normale attendue du flux.
• Schéma d’échec : validations erronées multiples ou demandes sans aboutissement.
• Destination : changements inhabituels dans le schéma des destinations au sein d’une application.
• Risque contextuel : indicateurs de changement d’appareil, de SIM ou de portabilité, traités comme des signaux et non comme des certitudes.
• Qualité du signal : des données incomplètes ou non fiables doivent réduire la confiance dans la décision, et non la durcir automatiquement.

Ce qu’il faut enregistrer sans conserver plus de données que nécessaire

Les journaux permettent d’expliquer une décision, d’enquêter sur les abus et de détecter les faux positifs. OWASP recommande de journaliser les réussites et échecs d’authentification, les tentatives de dépassement des limites et l’activité suspecte liée à la logique métier, en utilisant une taxonomie cohérente et documentée.

Pour chaque événement, conservez le contexte de ce qui s’est produit, quand, où et pour qui : horodatage, identifiant d’interaction, action, résultat, règle appliquée et niveau de confiance. Utilisez des identifiants pseudonymisés ou des références protégées lorsque cela est approprié pour le compte, le numéro, l’appareil ou la session.

N’enregistrez pas les secrets OTP, mots de passe, jetons d’accès, valeurs de session ni données personnelles inutiles. Appliquez le masquage, le hachage, le chiffrement ou la pseudonymisation selon le cas et veillez à ce que les contrôles d’accès aux journaux soient cohérents avec la sensibilité des données.

• ID d’interaction ou de transaction pour corréler la demande, l’envoi et la validation.
• Horodatage, action, résultat et motif de la décision.
• Identifiant de règle, entité limitée et état du quota, sans exposer de secrets.
• Référence pseudonymisée à la destination et aux autres signaux nécessaires à la corrélation.
• Contexte technique d’origine uniquement dans la mesure nécessaire à la sécurité et à l’enquête.
• Événements d’exception, de revue manuelle et de réversibilité afin de préserver la traçabilité.