Authentification « Silent Network » : une connexion sécurisée contre la fraude avec FastAPI et Kotlin

Sécurisez votre processus de paiement Python dans FastAPI contre la fraude. 

La fraude n'est plus une simple tâche administrative. C'est une décision prise en temps réel : soit par votre code d'authentification en 200 millisecondes, soit par les pirates à votre place. Ce tutoriel guide un ingénieur backend Python à travers les deux signaux côté opérateur qui comblent les lacunes laissées par les codes OTP par SMS : la détection de l’usurpation de carte SIM et l’authentification réseau silencieuse, toutes deux intégrées à une application FastAPI fonctionnelle que vous pouvez présenter à votre responsable technique dès aujourd’hui. Poursuivez votre lecture pour en savoir plus sur la fraude et le piratage de compte, ou passez directement à la mise en place et au fonctionnement du code à l’aide du README. 

Pourquoi est-ce important ? La fraude par prise de contrôle de compte représente désormais une perte annuelle de plusieurs millions pour les fintechs de taille moyenne et une charge de support à deux chiffres en pourcentage pour les équipes d'ingénieurs qui les soutiennent. Les deux mesures de défense les plus efficaces que vous pouvez intégrer dès aujourd’hui dans un processus de connexion Python sont la détection de l’usurpation de carte SIM (la carte SIM associée à ce numéro a-t-elle changé au cours des 7 derniers jours ?) et l’authentification réseau silencieuse (s’agit-il bien de la carte SIM réelle sur le réseau mobile réel correspondant à ce numéro, à l’instant même ?). Ces deux fonctionnalités s’exécutent côté opérateur. Elles sont toutes deux accessibles via les API du réseau Vonage. Aucune ne nécessite que l’utilisateur saisisse quoi que ce soit. 

Prochaines étapes : À l’issue de ce tutoriel, votre backend FastAPI intègre SIM Swap et Silent Auth dans une seule route de connexion, ne recourt à la vérification par code OTP SMS que lorsque la connexion réseau ne peut aboutir, et dispose des mesures de sécurité nécessaires en production (repli en cas de délai d’expiration, paramètres par défaut « fail-closed », hooks d’observabilité) avant que vous ne lui transmettiez du trafic réel. La prévention de la fraude de bout en bout n’est plus un système distinct à intégrer, mais consiste simplement en deux appels d’API au sein du flux d’authentification dont vous disposez déjà.

L'augmentation coûteuse de la fraude et des prises de contrôle de comptes

Vous avez besoin de consulter votre compte bancaire ? Pas de problème ! Il vous suffit de vous connecter au portail bancaire en ligne à l'aide de votre adresse e-mail et de votre mot de passe. Ensuite, afin de vérifier qu'il s'agit bien de vous, un SMS contenant un mot de passe à usage unique (OTP) est envoyé au numéro de téléphone enregistré dans votre dossier. Si c'est bien vous qui essayez de vous connecter, on part du principe que vous avez ce téléphone à portée de main. Si le code que vous saisissez correspond à celui généré par le processus de vérification, vous êtes authentifié et pouvez accéder à votre compte. 

Mais que se passerait-il si la personne qui reçoit ce SMS n'était pas vous ? Et si quelqu’un vous avait volé votre téléphone ? Et si quelqu’un avait piraté votre messagerie ? Et si la tentative de connexion avait été lancée par une personne utilisant un bot et disposant d’une liste de noms d’utilisateur et de mots de passe d’Accounts compromis, qu’elle utilise pour pratique du « credential stuffing »? 

Prise de contrôle de compte est un type de fraude qui se produit lorsqu'un pirate informatique parvient à accéder à un compte dont il n'est pas le propriétaire légitime. Une prise de contrôle de compte résulte généralement d'un échec d'authentification. Un échec d'authentification se produit lorsqu'un pirate informatique trompe un système afin qu'il reconnaisse comme légitime un utilisateur invalide ou incorrect. L'échec d'authentification reste l'un des les dix principaux risques de sécurité des applications recensés par l’Open Web Application Security Project (OWASP) pour la cinquième année consécutive. 

Fraude par prise de contrôle de compte a entraîné près de 13 milliards de dollars de pertes en 2023, soit une augmentation par rapport aux 11 milliards de dollars enregistrés en 2022. Le coût financier n’est pas le seul danger lié à la fraude et aux failles d’authentification des Applications ; l’atteinte à la confiance et à la réputation de la marque est encore plus coûteuse.

Fraud is no longer a back-office cleanup job.

Même si la fraude ne sera probablement jamais totalement éradiquée, il existe des stratégies que vous pouvez mettre en œuvre pour renforcer les niveaux de vérification et de sécurité, et contribuer ainsi à prévenir le piratage de comptes. Dans cet article de blog, nous aborderons ces stratégies, puis nous examinerons un exemple d'application (client Android avec serveur FastAPI ) ainsi que des extraits de code pour montrer comment Vonage Verify peut renforcer vos processus d’authentification grâce à des contrôles de substitution de carte SIM, à l’authentification silencieuse et au recours à des méthodes de vérification alternatives. 

Vous pouvez consulter le code de l'application de démonstration incluse dans cet article de blog et la mettre en œuvre en suivant le fichier fichier README. 

Qu'est-ce que l'authentification « Silent Network » et pourquoi remplace-t-elle le mot de passe à usage unique (OTP) par SMS ?

Avez-vous déjà été victime d'un piratage? Il y a de fortes chances que ce soit le cas. En décembre 2025, le Federal Bureau of Investigations (FBI) des États-Unis a mis au jour 630 millions de mots de passe compromis provenant de plusieurs appareils appartenant à un seul pirate informatique. Les implications de cette affaire sont considérables, mais surtout, cela illustre à quel point peu sûr est devenu le protocole d'authentification par nom d'utilisateur et mot de passe.  

L'authentification multifactorielle (MFA) et l'authentification à deux facteurs (2FA) offrent une couche de protection contre le vol d'identifiants de connexion en exigeant la présentation de plusieurs types de justificatifs d'identité pour accéder à un système. Les codes d'accès à usage unique (OTP) envoyés par SMS constituent une forme d'authentification à deux facteurs qui s'appuie sur le preuve de possession « quelque chose que vous possédez » qui permet de prouver que vous êtes bien la personne que vous prétendez être. En raison de l’omniprésence des téléphones portables, les OTP par SMS constituent l’une des méthodes d’authentification multifactorielle les plus couramment mises en œuvre. 

Malheureusement, en raison l'utilisation généralisée des codes OTP par SMS, les fraudeurs ont mis au point des stratégies pour contourner et compromettre cette méthode d'authentification multifactorielle (MFA), telles que : 

• Interception sur le réseau du système de signalisation n° 7 (SS7): une faille de protocole au niveau de l'opérateur qui permet aux pirates de rediriger des SMS vers eux-mêmes 

• Échange de carte SIM: Un pirate utilise des techniques d'ingénierie sociale pour convaincre l'opérateur de réattribuer le numéro de la victime à une nouvelle carte SIM 

• Hameçonnage: L'utilisateur est amené par ruse à saisir le mot de passe à usage unique (OTP) sur une page de connexion frauduleuse 

L'authentification réseau silencieuse (SNA) — ou « authentification silencieuse » en abrégé — est un contrôle basé sur la possession, effectué côté opérateur, qui redirige la session de données mobiles d’un téléphone via le réseau de l’opérateur sans que vous ayez besoin de saisir un code. Cela élimine la dépendance vis-à-vis d’un facteur externe (tel qu’un pirate) pour vérifier votre identité. 

L'authentification réseau silencieuse vérifie que l'appareil utilisant actuellement la session de données mobiles est bien le propriétaire du numéro de téléphone, sans envoyer de code. Elle fonctionne en redirigeant une requête HTTP vérifiée par l’opérateur via ce dernier. Contrairement à l’OTP par SMS, elle élimine le vecteur d’attaque SS7 ; cependant, elle ne protège pas à elle seule contre les attaques par échange de carte SIM (SIM Swap) : un contrôle anti-SIM Swap doit être utilisé en complément de l’authentification silencieuse pour parer à ce risque. Grâce à la Verify API, vous pouvez utiliser un backend Python FastAPI et un client mobile pour mettre en œuvre l’authentification silencieuse et renforcer la sécurité de vos applications. 

Qu'est-ce qu'une attaque par échange de carte SIM et comment s'en protéger ?

Une attaque par échange de carte SIM est un type de fraude par prise de contrôle de compte qui exploite certaines des failles inhérentes à l'authentification multifactorielle (MFA) par code OTP envoyé par SMS. Ce type d’attaque consiste à inciter un opérateur mobile à activer une nouvelle carte SIM que le réseau de l’opérateur associe ensuite au numéro de téléphone de la victime. Le propriétaire du numéro reste le même ; l’attaquant obtient simplement l’accès pour intercepter les SMS entrants et les communications vocales liées à ce numéro tant que le remplacement de la carte SIM passe inaperçu. Pour mener une attaque par échange de carte SIM, un pirate recueille des informations personnelles vous concernant, soit par le biais d’hameçonnage, soit à partir de listes de données volées disponibles sur le marché noir, soit par le biais de l’ingénierie sociale. Le pirate contacte ensuite votre opérateur mobile et utilise vos données personnelles pour convaincre le conseiller du service client d’activer une nouvelle carte SIM associée à votre numéro. Son appareil reçoit alors vos SMS et vos appels entrants. L’attaquant ne devient jamais le propriétaire du numéro (la facturation, le contrat et l’Account restent à votre nom) ; il obtient simplement un accès d’interception au niveau de la couche réseau jusqu’à ce que vous ou votre opérateur vous en rendiez compte. 

L'exemple le plus marquant d'une attaque par échange de carte SIM réussie s'est produit en 2019, lorsque l'account de Jack Dorsey, PDG de Twitter, a été piraté via un SMS frauduleux contenant un code OTP de l’authentification à deux facteurs (2FA). Cet incident a brutalement rappelé que personne n’est à l’abri de la fraude. De plus, le groupe à l’origine de ce piratage avait déjà réussi par le passé à prendre le contrôle de comptes en utilisant des méthodes similaires de substitution de carte SIM par ingénierie sociale. En d’autres termes, l’être humain reste le maillon faible de toute chaîne de sécurité. 

Outre les mesures pratiques que vous pouvez prendre pour éviter l'échange de carte SIM, comme l'utilisation de codes PIN, de mots de passe forts et uniques, et la vigilance quant aux informations que vous partagez publiquement, lorsque vous développez des processus d'authentification nécessitant une interaction mobile, vous pouvez intégrer une vérification rapide de l'état de la carte SIM d'un appareil. Le résultat de cette vérification peut ensuite orienter la suite de votre processus d’authentification, par exemple en recourant à une autre forme d’authentification à deux facteurs (2FA). 

Vérifier si une carte SIM a été remplacée au cours d'un délai défini permet de repérer un appareil suspect, de déclencher d'autres méthodes d'authentification et de contrer cette attaque courante. Grâce à l'API Vonage Identity Insights, vous pouvez récupérer des informations sur une carte SIM, telles que la date de son dernier remplacement, et déterminer ainsi la marche à suivre pour votre processus d'authentification. 

Qu'est-ce que l'API Vonage Identity Insights ?

L’API Vonage Number Insight fournit des informations en temps réel sur les numéros de téléphone, directement issues de l’infrastructure des opérateurs mobiles : ces données sont collectées de manière passive, sans interférence et impossibles à falsifier. Plus précisément, elle met à disposition des signaux provenant directement des opérateurs concernant un numéro de téléphone, notamment pour déterminer si son format est valide, si sa carte SIM a récemment été remplacée, ainsi que d’autres indicateurs de risque de fraude. Ces signaux peuvent être utilisés pour évaluer le niveau de risque associé à une action spécifique — telle qu’une connexion, une inscription, une récupération d’Account ou une transaction financière —, permettant ainsi une sécurité adaptative qui renforce la protection précisément au moment et à l’endroit où cela est nécessaire. Pour cet article de blog, nous utiliserons l’ indicateur « SIM Swap ». 

La fonctionnalité « SIM Swap » vous permet de déterminer si la carte SIM associée à un numéro de téléphone donné a récemment été remplacée. Elle est conçue pour atténuer l'impact d'une prise de contrôle de compte (attaque par échange de carte SIM), vous garantissant ainsi que le numéro de téléphone peut être utilisé dans de nombreux cas de figure, notamment pour la validation par SMS (2FA) ou comme canal de communication sécurisé.

Un appel type vers le point de terminaison Identity Insights pour le « SIM Swap » comprend la charge utile suivante :

{
    "phone_number": "14040000000",
    "purpose": "FraudPreventionAndDetection",
    "insights": {
        "sim_swap": {
            "period": 240
        }
    }
}

Ce point est expliqué plus en détail ci-dessous :  

Pour en savoir plus sur l'API et son fonctionnement, consultez la documentation de Vonage Identity Insights. 

Une requête réussie renvoie un 200 OK et un ensemble d’informations demandées. La réponse comprendra également un request_id: 

{
    "request_id": "aaaaaaaa-bbbb-cccc-dddd-0123456789ab",
    "insights": {
        "sim_swap": {
            "latest_sim_swap_at": "2024-07-08T09:30:27.504Z",
            "is_swapped": true,
            "status": {
                "code": "OK",
                "message": "Success"
            }
        }
    }
}

Grâce à cette réponse, vous pouvez déterminer comment vous souhaitez que votre processus de vérification se déroule. 

Qu'est-ce que la Verify API de Vonage ?

Verify API est le produit de nouvelle génération de Vonage dédié à l'authentification à deux facteurs (2FA). Grâce à Verify API, vous pouvez authentifier vos utilisateurs et prévenir la fraude grâce à une API simple et facile à utiliser qui élimine la complexité de la 2FA à l'échelle mondiale.  

Elle élargit les méthodes d'authentification traditionnelles en prenant en charge un éventail plus large de canaux, notamment les canaux « over-the-top » (OTT) tels que WhatsApp, ainsi que les SMS, la voix et les e-mails. L'API prend en charge à la fois les jetons Web JSON (JWT) et l'authentification de base. L’authentification de base est plus simple à mettre en place, mais ne prend pas en charge les fonctionnalités avancées telles que les listes de contrôle d’accès (ACL). Vous pouvez utiliser soit l’authentification JWT, soit l’authentification de base, mais pas les deux simultanément. Pour en savoir plus sur l’authentification, consultez la documentation.  

Dans les grandes lignes, la Verify API suit le processus suivant : 

1. Un utilisateur final déclenche une demande d'authentification à deux facteurs (2FA) dans une application 

2. Côté serveur, cette requête d'authentification à deux facteurs déclenche une requête vers la Verify API 

3. La Verify API envoie un code d'accès à usage unique (OTP) à l'utilisateur final via le canal — ou la séquence de canaux — que vous configurez pour votre processus d'authentification (SMS, appel vocal, WhatsApp, e-mail, etc.), ce qui vous offre une flexibilité totale pour définir le flux de vérification le mieux adapté à votre cas d'utilisation. 

4. L'utilisateur final fournit le mot de passe à usage unique (OTP) à l'application 

5. Cela déclenche une requête Verify visant à comparer le mot de passe à usage unique (OTP) fourni par l'utilisateur final à celui généré par Vonage. 

6. Le résultat de cette vérification détermine ensuite la suite des événements (l'utilisateur final est authentifié, etc.)  

A visual representation of a Verify request flow with summary callbacks.Une demande de vérification initiale type comprend la charge utile suivante, où chaque channel élément de la workflow liste définit la destination de l’OTP :

{"locale": "es-es",  
   "channel_timeout": 180,  
   "client_ref": "myPersonalRef",  
   "code_length": 4,  
   "code": "e4dR1Qz",  
   "brand": "ACME",  
   "template_id": "4ed3027d-8762-44a0-aa3f-c393717413a4",  
   "workflow": [  
      { "channel": "sms",  
         "to": "44770090000"},  
      { "channel": "voice",  
         "to": "44770090000" }  
   ] } 

 Ce point est expliqué plus en détail ci-dessous :  

Pour en savoir plus sur l'API et son fonctionnement, consultez la documentation de Vonage Verify.  

Une requête réussie renvoie un 202 OK pour indiquer que la demande de vérification a été lancée. La réponse comprendra également un request_id qui est nécessaire pour mener à bien le processus de vérification : 

{ "request_id": "c11236f4-00bf-4b89-84ba-88b25df97315"}   

Parallèlement, Vonage envoie un mot de passe à usage unique (OTP) à l'utilisateur final via le flux de travail configuré, en essayant chaque canal dans l'ordre dans lequel ils sont définis.  

Une fois que l'utilisateur final a reçu le mot de passe à usage unique (OTP) et l'a saisi dans l'application, une nouvelle requête est envoyée au verify point de terminaison avec le request_id en tant que paramètre de chemin d’accès (https://api.nexmo.com/v2/verify/:request_id) et contenant le mot de passe à usage unique (OTP) dans le corps de la requête pour la code clé dans la charge utile. 

Si le code fourni correspond au code généré et envoyé par Vonage, une 200 OK réponse est renvoyée. 

En quoi l'authentification silencieuse est-elle différente ?

Authentification silencieuse utilise la carte SIM (Subscriber Identity Module) d'un téléphone mobile pour vérifier l'identité d'un utilisateur sans aucune intervention de sa part. Elle compare le numéro de téléphone de l'utilisateur aux registres de son opérateur afin de confirmer qu'il est actif et valide. 

Une fois la requête vérifiée, vous pouvez continuer à authentifier l'utilisateur jusqu'à ce que la requête expire ou soit annulée par l'utilisateur. 

Pour intégrer l'authentification silencieuse à votre processus de vérification, ajoutez-la en tant que channel à la workflow liste figurant dans le corps de votre requête. Veuillez noter que silent_auth doit figurer en premier, car le workflow s'exécute dans l'ordre dans lequel il est défini : 

"workflow": [
    {
        "channel": "silent_auth",
        "to": "44770090000",
        "redirect_url": "https://acme-app.com/sa/redirect",
        "check_coverage": "true"
    },
    {
        "channel": "sms",
        "to": "44770090000"
    },
    {
        "channel": "voice",
        "to": "44770090000"
    }
]

Lorsque le silent_auth canal est inclus, la réponse contient un check_url en plus de la request_id: 

{
    "request_id": "c11236f4-00bf-4b89-84ba-88b25df97315",
    "check_url": "https://api.nexmo.com/v2/verify/c11236f4-00bf-4b89-84ba-88b25df97315/silent-auth/redirect"
}

La valeur de check_url est l’URL sur laquelle GET est ensuite effectuée via les données mobiles côté client. Il est important de noter que l’authentification silencieuse repose sur une réponse GSM vérifiée provenant de l’appareil pour prouver ses identifiants, réponse qui n’est pas envoyée si l’utilisateur est connecté au Wi-Fi. L’utilisateur doit donc déclencher la demande d’authentification en utilisant les données mobiles. (Nous examinerons plus en détail comment le SDK Android de Vonage peut forcer une connexion mobile lorsque nous aborderons le côté client.) 

Si le client parvient à effectuer une GET requête sur l’URL, Vonage répond avec le request_id et un code. 

Ce code est ensuite vérifié lors d’un appel vers le verify point de terminaison et, s’il correspond à l’OTP généré par Vonage, un 200 OK est renvoyé avec "status": "complete".  

Mise en place d'une solution complète de prévention de la fraude avec Python, Kotlin et Vonage

L'application présentée dans cet article de blog illustre un processus d'authentification minimal pouvant être utilisé comme étape supplémentaire dans le cadre de l'authentification à plusieurs facteurs (MFA). Vous trouverez le code sur la GitHub de la communauté Vonage. Le client Android, développé en Kotlin, interagit avec un serveur backend écrit avec FastAPI et utilise les API Vonage Insights et Verify API pour définir et exécuter un workflow d'authentification. 

L'application exécute la séquence suivante : 

1. L'utilisateur final voit s'afficher un écran de vérification lui demandant de saisir son numéro de téléphone. 

2. La saisie d'un numéro de téléphone déclenche l'envoi d'une requête au serveur backend, ce qui lance une série d'étapes de vérification. 

3. Le backend envoie une requête au point de terminaison Insights pour vérifier si la carte SIM a été remplacée dans un délai donné. 

4. Si la carte SIM a été remplacée récemment ou s'il n'est pas possible de déterminer ces informations, celle-ci est signalée. 

   1. Une carte SIM signalée peut indiquer qu'un appareil a été piraté. Cela remet en cause la fiabilité des autres méthodes de vérification basées sur les appareils mobiles ; l'application se rabat donc sur l'adresse e-mail enregistrée pour le numéro de téléphone fourni et y envoie un mot de passe à usage unique (OTP) via la Verify API. 

   2. Si l'utilisateur final reçoit et saisit un mot de passe à usage unique (OTP) correspondant à celui généré par Vonage, son identité est alors vérifiée ; en l'absence de correspondance, son identité n'est pas vérifiée. 

5. Si la carte SIM n'a pas été remplacée récemment, le processus se poursuit avec une authentification silencieuse. 

6. Si l'authentification silencieuse échoue ou n'est pas prise en charge par le réseau de l'opérateur mobile, l'application utilise alors un code OTP par SMS. 

   1. Si l'utilisateur final reçoit et saisit un mot de passe à usage unique (OTP) correspondant à celui généré par Vonage, son identité est alors vérifiée ; en l'absence de correspondance, son identité n'est pas vérifiée. 

7. Si l'authentification silencieuse s'effectue correctement, l'utilisateur final est authentifié.  

Les prérequis, la configuration de l'environnement et les étapes à suivre pour exécuter ce code sont décrits dans le fichier fichier README sur GitHub. Nous aborderons ci-dessous en détail les parties importantes du code. 

Utilisation de FastAPI et du SDK Python de Vonage pour définir le serveur backend

Afin de favoriser la séparation des responsabilités, nous définissons un ensemble de fonctions qui interagissent avec Vonage dans un fichier intitulé vonage_handlers.py. 

Initialisation des clients Vonage

Dans cet exemple d'application, nous utilisons à la fois les API Identity Insights et Verify API. Leurs points de terminaison étant légèrement différents, nous allons créer deux clients pour gérer cela. Dans les deux cas, VONAGE_APPLICATION_ID et VONAGE_PRIVATE_KEY_PATH sont fournis par Vonage lorsque vous créez une application. La configuration complète de cette application est décrite dans le dépôt README. 

verify_client = Vonage(
    Auth(
        application_id=os.environ["VONAGE_APPLICATION_ID"],
        private_key=os.environ["VONAGE_PRIVATE_KEY_PATH"],
    )
)

identity_insights_client = Vonage(
    Auth(
        application_id=os.environ["VONAGE_APPLICATION_ID"],
        private_key=os.environ["VONAGE_PRIVATE_KEY_PATH"],
    ),
    http_client_options={"api_host": "api-eu.vonage.com"},
)

Vérification de l'échange de carte SIM

Nous vérifions d'abord le statut de la carte SIM associée au numéro fourni par l'utilisateur final au client, puis nous renvoyons True, False, ou None: 

def check_sim_swap(phone: str) -> bool | None:
    """
    Returns True if SIM was swapped, False if not, None if carrier doesn't permit check.
    """
    insights_request = IdentityInsightsRequest(
        phone_number=phone,
        purpose="FraudPreventionAndDetection",
        insights=InsightsRequest(
            format=EmptyInsight(), sim_swap=SimSwapInsight(period=240)
        ),
    )
    return identity_insights_client.identity_insights.requests(
        insights_request
    ).insights.sim_swap.is_swapped

Cette fonction effectue une requête vers le point de terminaison Identity Insights et renvoie au client les informations relatives au « SIM Swap » pour le numéro fourni par l'utilisateur final. 

Initialiser le processus de vérification silencieuse de l'authentification

Nous lançons le processus de vérification à l'aide de la start_silent_auth fonction suivante : 

def start_silent_auth(phone: str) -> dict:
    """
    Starts Silent Auth verification.
    Returns channel, request_id, and check_url.
    Raises HttpRequestError with 412 if Silent Auth unavailable.
    """
    request = VerifyRequest(
        brand="DemoApp", workflow=[SilentAuthChannel(to=phone)], coverage_check=True
    )
    response: StartVerificationResponse = verify_client.verify.start_verification(
        request
    )
    return {
        "channel": "silent_auth",
        "request_id": response.request_id,
        "check_url": response.check_url,
    }

Nous incluons le coverage_check paramètre pour vérifier de manière synchrone si le réseau de destination de l’utilisateur final est pris en charge par l’authentification silencieuse. Si ce n’est pas le cas, Vonage renvoie une 4xx réponse. Cette vérification initiale évite tout décalage pouvant résulter de flux de redirection inutiles. Au lieu d’effectuer plusieurs GET tentatives, votre application peut se rabattre sur une autre méthode de vérification si l’authentification silencieuse ne prend pas en charge le réseau de l’opérateur de l’utilisateur final. Cela peut se traduire par une meilleure expérience utilisateur. 

Si le réseau de l'utilisateur final prend en charge l'authentification silencieuse et que la GET la requête sur le check_url fournie par Vonage aboutit, alors un request_id et code est renvoyé. Ce code est vérifié dans une autre fonction. 

Recours à d'autres méthodes d'authentification à mot de passe à usage unique (OTP)

En fonction des résultats du contrôle de « SIM Swap » et de la tentative d'authentification silencieuse, vous pouvez envisager de recourir à une autre méthode OTP. 

En cas de substitution de carte SIM, il peut être préférable de recourir à une méthode d'authentification par mot de passe à usage unique (OTP) qui ne repose pas uniquement sur un appareil mobile. Si une carte SIM a été substituée de manière frauduleuse, l'authentification silencieuse pourrait ne plus être fiable. Le remplacement d'une carte SIM n'est pas toujours le résultat d'un piratage de compte, mais mieux vaut prévenir que guérir : vous pouvez donc envisager d'envoyer le mot de passe à usage unique (OTP) à une autre adresse. 

Dans la start_email fonction, nous utilisons la Verify API pour lancer un processus de vérification par e-mail :

def start_email(phone: str, email: str) -> dict:
    """
    Starts email OTP verification.
    Returns request_id.
    """
    request = VerifyRequest(
        brand="DemoApp",
        workflow=[EmailChannel(to=email)],
    )
    response = verify_client.verify.start_verification(request)
    return {"request_id": response.request_id}

Si la carte SIM est pas été remplacée, mais que l'opérateur de l'utilisateur final n'est pas pris en charge ou que l'authentification silencieuse échoue, nous recourons alors à un mot de passe à usage unique (OTP) par SMS : 

def start_sms(phone: str) -> dict:
    """
    Starts SMS OTP verification.
    Returns channel and request_id.
    """
    logger.info(f"Starting SMS fallback with: {phone}")
    request = VerifyRequest(
        brand="DemoApp",
        workflow=[SmsChannel(to=phone)],
    )
    response = verify_client.verify.start_verification(request)
    return {"channel": "sms_otp", "request_id": response.request_id}

Vérification du mot de passe à usage unique (OTP)

Enfin, nous effectuons un appel vers le verify point de terminaison en utilisant le request_id et en fournissant le code transmis soit par l’utilisateur final sous forme de mot de passe à usage unique (OTP) par e-mail ou SMS, soit par le client à la suite d’une authentification silencieuse : 

def check_code(request_id: str, code: str) -> bool:
    """
    Validates OTP code with Vonage. Returns True if verified.
    """
    response = verify_client.verify.check_code(request_id, code)
    return {"verified": True, "status": response.status}

Le serveur backend : tout mettre en place avec FastAPI

FastAPI est un framework web haute performance permettant de créer des API de services basées sur HTTP en Python. Ce qui distingue FastAPI des autres frameworks web Python, c’est son alignement étroit avec Pydantic, une bibliothèque de validation de données pour Python. Ce couplage permet à FastAPI de valider, de sérialiser et de désérialiser les données. Il offre ainsi une méthode plus déclarative pour spécifier la structure et les types de données des requêtes entrantes, telles que les corps HTTP, et des réponses sortantes. FastAPI génère également automatiquement des spécifications OpenAPI. L’ensemble de ces fonctionnalités le rend particulièrement adapté aux API REST modernes, au développement de microservices et aux applications nécessitant des fonctionnalités en temps réel. 

Le fichier main.py contient nos routes FastAPI. 

Dans l'application d'exemple, nous recourons à un mot de passe à usage unique (OTP) envoyé par e-mail en cas de changement de carte SIM. Dans une application déployable en production, cette adresse e-mail est fournie par l'utilisateur final lors de la création de son compte et stockée dans une base de données. Dans notre exemple d’application minimale, vous fournissez une adresse e-mail de test qui est stockée en mémoire. Ce stockage en mémoire simule une base de données à l’aide des variables d’environnement que vous indiquez dans le .env fichier : 

USER_EMAIL_STORE = {os.environ["USER_PHONE_NUMBER"]: os.environ["USER_EMAIL"]}

Le /verification processus effectue une vérification de changement de carte SIM et, en fonction du statut de la carte SIM, lance un processus de vérification par authentification silencieuse. Si sim_swapped est False mais que l’authentification silencieuse aboutit à un 412 (ce qui signifie que le réseau de l’utilisateur final n’est pas pris en charge), nous revenons alors à l’OTP par SMS : 

@app.post("/verification")
async def start_verification(req: VerificationRequest):
    """
    Starts the verification process:
    - Check if SIM is swapped-- if sim_swapped: True, fallback to email
    - If sim_swapped: False, begin Silent Authentication
    """
    phone = req.phone
    logger.info(f"Beginning authentication process for: {phone}")

    try:
        sim_swapped = check_sim_swap(phone)
        logger.info(f"Swap status for {phone}: {sim_swapped}")

        if sim_swapped or sim_swapped is None:
            logger.info("SIM swap flagged, stepping up to email")
            return {"channel": "email_stepup", "request_id": None}

        return start_silent_auth(phone)

    except Exception as e:
        raise HTTPException(status_code=500, detail=str(e))

@app.post("/fallback-sms")
async def fallback_sms(req: VerificationRequest):

    phone = req.phone
    # Uncomment the line below and comment out the line above
    # to test this app with a Virtual Operator number and receive an OTP
    # to a real phone number
    # phone = os.environ["USER_PHONE_NUMBER"]

    logger.info(f"SMS fallback requested, sending to: {phone}")
    try:
        return start_sms(phone)
    except Exception as e:
        raise HTTPException(status_code=500, detail=str(e))

Si sim_swapped est True, nous renvoyons {"channel": "email_stepup", "request_id": None} ce qui incitera le client à appeler la méthode /send-email-otp: 

@app.post("/send-email-otp")
async def send_email_otp(req: VerificationRequest):
    """
    Starts the verification process via email:
    - Check if there is a stored email -- if no email, raise exception
    - If there is an email, begin verification
    """
    phone = req.phone

    logger.info(f"Stepping up to email for verification process for: {phone}")
    email = USER_EMAIL_STORE.get(phone)
    logger.info(f"Getting email address from simulated user database: {email}")

    if not email:
        raise HTTPException(status_code=404, detail="No email on file for this number")

    logger.info(f"Beginning email verification for: {email}")
    try:
        return start_email(phone, email)
    except Exception as e:
        raise HTTPException(status_code=500, detail=str(e))

Enfin, nous utilisons la /check-code route pour terminer le processus d’authentification : 

@app.post("/check-code")
async def verify_code(req: CheckCodeRequest):
    request_id = req.request_id
    code = req.code
    logger.info(f"Checking code for request_id: {request_id} with code: {code}")
    try:
        response = check_code(request_id, code)
        logger.info("Verification success!")
        return response
    except Exception as e:
        logger.info("Verification failure")
        return {"verified": False, "status": str(e)}

Utilisation du Vonage Client SDK pour définir le client

Le client de cette application d'exemple est développé avec Kotlin et utilise des bibliothèques modernes telles que OkHttp et les coroutines Kotlin ainsi que Jetpack Compose pour l'interface utilisateur. Le code complet est disponible dans le dépôt GitHub. Le client offre une interface mobile minimaliste. 

Il utilise également le SDK Android de Vonage pour effectuer la partie « authentification silencieuse » du processus de vérification dans le ApiClient.kt fichier : 

    suspend fun checkSilentAuth(url: String): String = withContext(Dispatchers.IO) {
        val params = VGCellularRequestParameters(
            url = url,
            headers = mapOf(),
            queryParameters = mapOf(),
            maxRedirectCount = 10
        )

        Log.d("DemoApp", "Attempting Silent Authentication ...")

        val response = VGCellularRequestClient.getInstance()
            .startCellularGetRequest(params, false)

        val sdkError = response.optString("error", "")
        if (sdkError.isNotEmpty()) {
            throw SilentAuthUnavailableException("SDK error: $sdkError")
        }

        val httpStatus = response.optInt("http_status", -1)
        if (httpStatus !in 200..299) {
            throw SilentAuthUnavailableException("HTTP $httpStatus")
        }

        val code = response.optJSONObject("response_body")?.optString("code", null)
        if (code.isNullOrBlank()) throw SilentAuthUnavailableException("Silent auth response missing 'code'")

        code
    }

Cette ligne utilise la bibliothèque client Vonage pour Android pour forcer une connexion mobile afin d'effectuer une GET demande sur la check_url générée par Vonage lorsque nous avons lancé le processus de vérification : 

val response = VGCellularRequestClient.getInstance()
    .startCellularGetRequest(params, false)

Si la GET requête aboutit, un code est renvoyé et transmis au backend pour vérification. 

Prévention de la fraude de bout en bout

Suivez le fichier fichier README pour obtenir le code permettant de lancer l'application d'exemple et de la tester. Veillez à configurer le Network Registry Playground afin de pouvoir commencer immédiatement à tester les fonctionnalités réseau. Cette application d'exemple fonctionne mieux avec un appareil en service, mais il convient de garder à l'esprit quelques points importants : selon votre opérateur mobile, l'API Identity Insights et le canal de vérification « Silent Authentication » peuvent ne pas fonctionner. Consultez la documentation sur la couverture de Vonage pour vérifier si votre opérateur est pris en charge. Vous pouvez également utiliser le opérateur virtuel Vonage pour tester différents scénarios.

En résumé

La fraude et le piratage de comptes constituent des problèmes coûteux, non seulement sur le plan financier, mais aussi en termes de confiance envers la marque et de crédibilité des développeurs, qui mettent des années à se construire. Bien qu’il soit largement utilisé, le code OTP par SMS traditionnel présente des vulnérabilités bien connues : les failles du protocole SS7, les attaques par « SIM swap » et le phishing compromettent tous sa fiabilité en tant que deuxième facteur d’authentification autonome. 

Dans cet article de blog, nous avons examiné une approche multicouche de l'authentification qui s'attaque de front à ces faiblesses : 

• Détection d'un échange de carte SIM : Grâce à l’API Vonage Identity Insights, vous pouvez vérifier si un numéro de téléphone a récemment été réattribué à une nouvelle carte SIM et utiliser cette information pour prendre des décisions plus éclairées quant à la procédure d’authentification à suivre. Une réattribution récente constitue un signal d’alerte justifiant le recours à un canal de vérification plus fiable. 

• Authentification silencieuse: Plutôt que de compter sur l'utilisateur pour recevoir et saisir un code, le canal d'authentification silencieuse de la Verify API vérifie directement l'identité d'un appareil via le réseau de l'opérateur. Pas de code, aucune saisie de la part de l'utilisateur, aucun risque d'interception. 

• Solutions de repli élégantes : Il n'existe pas de méthode unique qui fonctionne dans tous les cas de figure. Lorsqu'une authentification silencieuse n'est pas prise en charge par un opérateur, l'application utilise alors un mot de passe à usage unique (OTP) par SMS. Lorsqu'un échange de carte SIM est détecté, l'application passe à l'envoi d'un OTP par e-mail, un canal qui n'est pas lié à l'appareil potentiellement compromis. 

L'application exemple montre comment ces trois stratégies peuvent être combinées pour former un processus d'authentification cohérent et concret, à l'aide du SDK Python de Vonage et du SDK Android de Vonage. 

La fraude ne sera sans doute jamais totalement éradiquée, mais grâce à des outils adaptés et à une approche réfléchie et à plusieurs niveaux, vous pouvez considérablement compliquer la tâche des pirates — tout en facilitant grandement l'accès aux utilisateurs légitimes. 

Lectures complémentaires et ressources

• Documentation de l'API Vonage Verify API: La Verify API est notre produit de nouvelle génération dédié à l'authentification à deux facteurs (2FA).

• Documentation de l'API Identity Insights de Vonage: La Number Insight API de Vonage fournit des informations en temps réel sur la validité, l'accessibilité et le statut d'itinérance d'un numéro de téléphone, et vous indique comment formater correctement ce numéro dans votre application.

• Espace de test du registre du réseau: L'espace de test permet aux développeurs de commencer à utiliser les fonctionnalités réseau en attendant que leur profil d'entreprise soit validé par les opérateurs.

• Intégration numérique dans le secteur bancaire grâce à l'authentification silencieuse: Réduisez les frictions et les abandons lors de l'intégration numérique en privilégiant l'authentification silencieuse via la Verify API plutôt que le mot de passe à usage unique (OTP).

Q1. Qu'est-ce que l'authentification réseau silencieuse ? 

L'authentification réseau silencieuse (SNA) est une méthode mise en œuvre par l'opérateur qui vérifie le numéro de téléphone d'un utilisateur en acheminant la session de données mobiles de l'appareil via le réseau de l'opérateur. Aucun code n'est envoyé à l'utilisateur et aucune saisie n'est requise. Elle élimine les vecteurs d'attaque liés à l'interception SS7 et au « SIM Swap » que l'OTP par SMS laisse ouverts.  

Q2. Quelle est la différence entre l'authentification réseau silencieuse et la détection d'usurpation de carte SIM ? 

 L'authentification silencieuse du réseau vérifie que la carte SIM actuellement active sur la session de données mobiles est bien celle que l'opérateur associe au numéro de téléphone vérifié. La détection de « SIM Swap » vérifie si une nouvelle carte SIM (physique ou eSIM) a été récemment activée et associée à ce numéro chez l'opérateur. La propriété du numéro lui-même (facturation, contrat, Account) ne change pas lors d’un « SIM Swap » ; l’attaquant obtient un accès d’interception au niveau de la couche de routage du réseau, et non la propriété légale. L’authentification silencieuse du réseau (SNA) confirme que la liaison actuelle entre la carte SIM et le numéro est inchangée, tandis que la détection de « SIM Swap » signale si cette liaison a été récemment mise à jour. En combinant ces deux vérifications dans le même processus de connexion, on peut détecter les attaquants qui ont déjà convaincu un opérateur de leur délivrer une carte SIM associée au numéro de la victime avant qu’ils ne tentent de se connecter. 

Q3. L'authentification réseau silencieuse fonctionne-t-elle sur le Wi-Fi ? 

Non. L'authentification réseau silencieuse nécessite une session de données mobiles active, car le flux CAMARA transite par le réseau de l'opérateur et non par Internet. Les appareils connectés uniquement au Wi-Fi, les tablettes sans carte SIM et les ordinateurs de bureau ne peuvent pas effectuer la redirection vers les données mobiles. Vous devez mettre en place une solution de secours : l'API Vonage Verify avec OTP par SMS ou vocal constitue la solution de secours standard et peut être déclenchée à partir du même Client SDK Python de Vonage. 

Q4. De quelles bibliothèques Python ai-je besoin pour l'authentification réseau en mode silencieux avec Vonage ? 

Vous avez besoin de Vonage (le SDK Python de Vonage disponible sur PyPI), de fastapi, d'uvicorn et de python-dotenv. En production, ajoutez redis-py pour stocker les identifiants `auth_request_ids` entre les routes d'initialisation et de rappel, ainsi que slowapi ou un middleware personnalisé pour limiter le débit de l'endpoint d'authentification.