Les résultats de requête 3-D Secure peuvent révéler des indices sur les comptes
The 3DS Oracle: BIN Attack via the Network · arXiv:2610.32206
En termes simples
Lors d’un paiement en ligne, 3-D Secure vérifie une carte avant l’autorisation du paiement. Cette étude cherche à savoir si le premier résultat présenté à un appelant révèle quelque chose sur le compte, même si aucun défi ni paiement ne suit.
Les chercheurs ont envoyé des requêtes à une intégration de paiement sans exécuter son logiciel de navigateur. Dans six des sept groupes de numéros de carte testés, une carte qu’ils contrôlaient a reçu un premier résultat différent de celui de trois numéros voisins.
Ce test montre un signal possible dans ce contexte précis ; il ne prouve pas que les numéros voisins étaient invalides ou inutilisables.
La recherche
Un contrôle d’authentification pour un paiement en ligne peut-il révéler des informations liées à un compte avant l’autorisation du paiement ? Un défi peut rester inachevé, alors que le résultat affiché dès la première requête varie d’une entrée à l’autre.
Cette différence pourrait aider quelqu’un à filtrer des numéros candidats, sans prouver qu’une carte est valide ou utilisable.
L’étude teste si les premiers résultats 3-D Secure révèlent des différences liées aux comptes et observe une séparation dans certains cas limités en conditions réelles.
Dans une intégration Braintree/Cardinal testée, les chercheurs ont comparé chaque carte de référence dont ils savaient qu’elle avait été attribuée à trois numéros voisins de la même plage.
Un appelant autonome a envoyé des requêtes sans exécuter de logiciel de navigateur et consigné le premier résultat visible, en s’arrêtant avant la suite d’un défi ou toute autorisation financière.
Dans six des sept cohortes testées, le résultat de la carte de référence différait de ceux des trois numéros de comparaison ; une cohorte a renvoyé la même catégorie « défi requis » pour toutes les entrées.
Cela montre que les premiers résultats peuvent distinguer des entrées dans certains cas testés, tandis qu’une demande de défi ne prouve ni que l’authentification a été menée à terme ni que le compte est valide.
Le résultat en conditions réelles provient d’une seule intégration Braintree/Cardinal sur le canal navigateur et d’un ensemble restreint d’entrées. L’étude n’a pas vérifié si les numéros candidats avaient été attribués, observé le traitement interne, mené les défis à terme ni tenté d’autoriser un paiement.
Elle n’établit donc ni un test universel de validité des comptes ni la fréquence du phénomène à l’échelle des réseaux.
Ce que montrent les preuves
- La question avant l’autorisation
L’article étudie si un appelant peut déduire des informations liées à un compte à partir du premier résultat de 3-D Secure (3DS), avant l’autorisation financière. Ce résultat peut refléter la façon dont une demande d’authentification est traitée, mais une demande de défi ne signifie pas que le défi a été mené à terme, et un résultat ne prouve pas qu’une carte peut servir à payer.
Les auteurs associent une analyse des protocoles et de l’intégration à des tests limités en conditions réelles ainsi qu’à un examen distinct de documents publics.
- Tester le résultat visible
Pour examiner ce qu’un appelant pouvait voir, les chercheurs ont utilisé un client HTTP autonome avec une autorisation valide pour leur propre intégration commerçant. Il a envoyé des données synthétiques sur le navigateur et l’appareil et reçu des résultats de requête sans exécuter de logiciel de navigateur.
Le client s’est arrêté avant toute suite de défi ou autorisation de paiement. La mesure portait sur le premier résultat visible par l’appelant dans l’intégration, et non sur les messages bruts échangés en interne par les systèmes du réseau de paiement ou de l’émetteur.
- Une tendance avec une exception
Les chercheurs ont comparé une carte dont ils savaient qu’elle avait été attribuée et qu’ils contrôlaient à trois numéros voisins de la même plage, qui avaient passé un contrôle élémentaire de format. Dans six des sept cohortes de numéros de carte testées, la catégorie du premier résultat de la carte de référence différait de celles des trois entrées de comparaison.
Dans la cohorte restante, les quatre entrées ont reçu un résultat indiquant qu’un défi était requis. L’unité de comparaison était la cohorte, et non chaque session répétée ; le résultat distingue certaines entrées dans certains cas, sans valider un outil de classification.
- Interpréter les indices avec prudence
L’étude interprète aussi les identifiants de transaction renvoyés à l’aide d’une règle du protocole : quand le Directory Server crée une réponse au nom du système de l’émetteur, leurs identifiants doivent correspondre. Des identifiants correspondants ou distincts peuvent donc être compatibles avec différents niveaux de traitement, si les champs sont correctement mis en correspondance et si la spécification est respectée. Ils ne révèlent pas directement le traitement interne et ne prouvent pas qu’un compte existe.
Lors d’une comparaison distincte, des entrées précédemment bloquées ont reçu des réponses au niveau de l’émetteur en passant par des proxys résidentiels répartis, dans une seule intégration et avec un petit ensemble de proxys.
- Ce que les éléments étayent
Un examen distinct de documents publics a trouvé des exemples de services payants et de logiciels qui utilisent les résultats 3DS pour filtrer des identifiants candidats. Les auteurs interprètent ces éléments, avec les observations en conditions réelles, comme une raison de limiter les détails exposés dans les réponses et de traiter les catégories de résultat de manière cohérente.
Comme le test en conditions réelles portait principalement sur une seule intégration, sans vérifier si les numéros candidats avaient été attribués ni observer le traitement interne du réseau, les éléments ne démontrent ni un test universel de validité des comptes ni la fréquence du signal.
Détails
- Auteurs de l’article original
- Wasif Faisal, Suprava Saha Dibya
- Soumis à arXiv
- Licence
- arXiv non-exclusive