Remise et fraude de l’OTP
Où fuit un mot de passe à usage unique, ce qu’un accusé de remise peut dire ou non, et les contrôles et métriques qui tiennent un flux d’OTP.
Un mot de passe à usage unique prouve la maîtrise d’un numéro au moment où il est saisi. Il ne prouve pas l’identité, et un accusé de remise ne prouve pas qu’une personne a lu le code. La remise, l’interception, le recyclage du numéro et le formulaire lui-même décident si la vérification tient.
Faits clés
- Un OTP prouve la maîtrise d’un numéro à cet instant, pas l’identité.
- Un accusé de remise décrit un état du réseau, pas la lecture du code par une personne.
- Le recyclage du numéro, le changement de SIM, le renvoi et l’hameçonnage sont les principales fuites.
- Les limites de débit, l’enregistrement de l’expéditeur et les contrôles du numéro réduisent l’abus ; aucun ne prouve l’identité.
Sur cette page
Ce que prouve un OTP
Un OTP répond à une question : la personne en face de vous peut-elle recevoir un message sur ce numéro maintenant ? C’est utile pour récupérer un compte et se connecter, parce que cela rattache la session à quelque chose que l’utilisateur contrôle. Ce n’est pas un document d’identité. Le numéro peut être recyclé, passer sur une autre SIM, être renvoyé ou être lu par une autre personne du foyer.
La distinction compte dès la conception. Si l’action est de faible valeur, un OTP est proportionné. Si elle déplace de l’argent, change un mot de passe ou ajoute un bénéficiaire, associez le code à une seconde vérification : un délai, une confirmation dans une session existante, un rappel vers un canal connu ou une revue manuelle. Le code est un facteur, pas toute la décision.
Le chemin et les points où le code fuit
- Application
- Passerelle SMPP
- SMSC
- HLR / HSS
- MSC / MME
- Téléphone
- Accusé de remise
Description textuelle
L’application remet le code à une passerelle, le centre de messagerie interroge l’abonné et le commutateur qui le sert remet au téléphone. Un accusé revient par la même chaîne. Le code peut fuir dans l’application, dans le téléphone, dans le numéro lui-même ou par la personne qui le reçoit. Le chemin réseau explique la remise ; il n’explique pas la personne qui partage le code.
Où fuit un OTP
Un changement de SIM déplace le numéro vers une nouvelle carte. L’attaquant convainc une boutique ou une ligne de support qu’il est le titulaire, et le code suivant part vers la nouvelle SIM. Le recyclage du numéro produit le même effet sans attaquant : l’opérateur réattribue un numéro inactif, et le nouveau titulaire reçoit un code destiné à l’ancien compte. Les deux justifient de vérifier si un numéro a été porté ou réattribué récemment.
Le renvoi et la messagerie vocale transcrite envoient le message vers une autre boîte. L’hameçonnage copie le formulaire et collecte le code directement, si bien que le réseau ne voit jamais d’attaque. L’interception sur le chemin réseau est plus rare et hors du contrôle de l’application ; la réponse pratique est un second facteur, pas un code plus long. Lisez l’entrée OTP du glossaire pour les définitions.
Des contrôles utiles
Limitez la fréquence à laquelle un numéro, une adresse IP et un appareil peuvent demander un code. Utilisez une validité courte, un seul usage par code et liez le code à la session qui l’a demandé. Enregistrez l’expéditeur et gardez un contenu sobre : un code qui ressemble à du marketing peut être filtré, et un code filtré produit un ticket de support, pas une connexion.
Vérifiez le numéro avant de lui faire confiance. Un numéro qui ne peut pas recevoir de SMS, qui a été porté récemment ou qui a un historique de réinitialisations mérite une étape supplémentaire. Pour les actions de forte valeur, exigez une session existante ou un second canal. Journalisez la demande, l’envoi, l’accusé et la saisie du code comme des événements distincts, pour distinguer un problème de remise d’un problème d’utilisateur.
Concevez le code avec le même soin. Générez-le depuis une source cryptographique, stockez un hachage, faites-le expirer en quelques minutes, autorisez un seul usage correct et plafonnez les tentatives par code et par session. Ne révélez pas si le numéro existe. Créez l’enregistrement du compte avant l’envoi, pour qu’une reprise n’ouvre pas un compte qui ne se termine jamais.
Cinq métriques, avec définitions
| Métrique | Définition | Ce qu’elle indique |
|---|---|---|
| Taux de remise | Accusés de remise divisés par messages envoyés | Si le réseau a accepté le message ; pas si une personne l’a lu |
| Taux de réussite | Codes saisis divisés par messages remis | Si le message et le formulaire ont fonctionné pour l’utilisateur |
| Délai de remise | Médiane et 95e centile de l’envoi à l’accusé | Si la route est lente et combien de temps l’utilisateur attend avant de redemander |
| Taux de renvoi | Renvois divisés par messages remis | Si les utilisateurs attendent trop, se trompent ou ne voient jamais le premier message |
| Taux de blocage | Demandes refusées par les règles de risque divisées par les tentatives | Si les règles sont trop strictes, trop laxistes ou si le trafic est abusif |
Suivez-les par marché, expéditeur et route. Une moyenne globale cache la route qui échoue.
Mesurez le flux, pas l’envoi
Un envoi qui renvoie un message ID n’est pas un code remis. Un code remis n’est pas une connexion terminée. Construisez l’entonnoir avec les événements que vous contrôlez : envoi, accusé, saisie du code, succès. Comparez-le à la vue du fournisseur. Un écart entre votre taux de remise et le sien peut être un accusé qui n’a jamais atteint votre gestionnaire, pas un message qui n’a jamais atteint le téléphone.
Revoyez le flux quand une métrique bouge. Une baisse de réussite avec une remise stable désigne le formulaire, l’expiration du code ou l’expéditeur. Une baisse de remise avec un envoi stable désigne la route, le numéro ou le filtre de contenu. Une hausse des renvois désigne le délai de remise. Corrigez l’étape que les données nomment, pas la plus facile à changer.
Fixez une date de revue pour tout le flux. Les numéros changent de main, les routes changent et les modèles vieillissent. Un flux qui marchait au lancement peut échouer en silence six mois plus tard, avec le même code et le même fournisseur.
Vérifiez vos acquis
-
Un utilisateur transfère le code à un ami. Le code prouve-t-il encore l’identité ?
Non. Il prouve que le numéro pouvait recevoir le code à cet instant. Quiconque a le code peut l’utiliser.
-
Un accusé dit remis, mais l’utilisateur ne voit jamais le code. Que vérifiez-vous ?
L’état du téléphone, l’application de messages et le filtre anti-spam, l’expéditeur et la route. Un accusé de remise est un état du réseau, pas l’écran du téléphone.
-
Pourquoi le taux de réussite est-il plus utile que le taux de remise ?
La remise s’arrête au réseau. La réussite inclut l’utilisateur, l’expiration du code et le formulaire, là où la plupart des échecs apparaissent.
Les réponses s’affichent sur demande. Rien n’est noté, stocké ni envoyé.
Questions fréquentes
Un OTP est-il la même chose que l’authentification à deux facteurs ?
Les codes plus longs sont-ils plus sûrs ?
Un accusé de remise prouve-t-il que l’utilisateur a lu le code ?
Faut-il renvoyer automatiquement ?
Que faut-il journaliser ?
Les accusés indiquent remis mais les utilisateurs ne reçoivent rien. Que vérifier avant de changer de fournisseur ?
Termes rencontrés
Voir aussi
- Se connecter en SMPP et en HTTP
Passer d’une route de test à la production sans casser les binds, les fenêtres ni les accusés : débit, keep-alive, codage, callbacks et pannes.
- Pack de modèles RFQ et RFP
Listes de champs pour les demandes de SMS en gros, eSIM et données, IoT et connectivité vers la Chine, avec une liste de contrôle en ligne.
- Rapport type de test de route
Exemple statique anonymisé d’un rapport de test de route : ce que vérifie un test de route, comment lire les échecs et ce qui déclenche une revue.
Produits associés
Passez à la pratique
Indiquez le trafic, la destination et la mesure nécessaire ; nous répondons avec l’étape suivante.