🔑 Authentifier sans code à usage unique

Pourquoi le code par SMS s'arrête

Le code à usage unique reçu par SMS est une suite de chiffres à validité limitée, envoyée par l'émetteur sur le numéro de téléphone mobile qu'il a enregistré pour ce porteur. Le porteur le saisit dans la page de paiement. Ce code a porté la mise en conformité européenne de 2019 parce qu'il ne demandait rien au porteur, ni installation, ni enrôlement, ni appareil neuf. Son abandon est décidé par les réseaux et par les émetteurs, en l'absence de toute interdiction réglementaire. Dans l'Espace économique européen, l'avis de l'Autorité bancaire européenne du 21 juin 2019 range la carte SIM parmi les éléments de possession valides. Le code par SMS reste donc formellement conforme quand un second facteur l'accompagne. Trois motifs expliquent son retrait, le coût du canal, la facilité avec laquelle un fraudeur obtient le code, et les feuilles de route que les réseaux ont publiées.

Le code par SMS est un secret transmissible. Quiconque en prend connaissance peut l'employer, et aucun élément du code ne le rattache au site sur lequel il est saisi. Trois chemins d'attaque en découlent, dont aucun ne réclame de compétence cryptographique. L'échange frauduleux de carte SIM transfère le numéro vers un appareil que l'attaquant contrôle, lequel reçoit alors les messages destinés au porteur. Un logiciel malveillant installé sur le téléphone lit la notification à la place du porteur. Le troisième chemin est le moins coûteux pour l'attaquant, puisqu'il n'emploie aucun moyen technique. Un appel téléphonique suffit, au cours duquel la victime dicte elle-même le code à un faux conseiller bancaire.

Le coût du canal se décompose en deux postes. Le SMS applicatif se facture au message et par pays, selon des grilles d'opérateurs et d'agrégateurs que l'émetteur n'est guère en position de négocier. S'y ajoute une fraude propre au canal, l'inflation artificielle de trafic. Un attaquant déclenche des envois massifs de codes vers des plages de numérotation dont il partage les frais de terminaison. Il facture ainsi sa propre attaque à sa victime. Les volumes concernés ne sont publiés ni par les opérateurs, ni par les émetteurs. Le mécanisme est documenté par les fournisseurs de messagerie applicative. Un formulaire d'inscription mal protégé devient alors une dépense qui se reproduit tant que l'envoi de codes reste déclenchable sans contrôle.

Les positions réglementaires diffèrent d'une zone à l'autre. L'Espace économique européen n'a prononcé aucune interdiction. Le rapport conjoint de l'Autorité bancaire européenne et de la Banque centrale européenne publié le 15 décembre 2025 constate un écart de fraude en faveur des opérations authentifiées, constat qui ne s'accompagne d'aucune mesure contraignante. Hors d'Europe, plusieurs banques centrales ont tranché plus vite. La Reserve Bank of India a ouvert l'authentification aux clés d'accès liées à l'appareil et à la biométrie, avec effet au 1er avril 2026. Bank Negara Malaysia a écarté le code par SMS comme second facteur autonome fin 2025. Un émetteur présent dans plusieurs de ces zones ne peut donc plus servir partout le même dispositif, puisque le code par SMS, qui reste admis dans l'Espace économique européen, ne satisfait ni la direction indienne ni la politique malaisienne.

Le calendrier des réseaux prend la forme d'engagements commerciaux assortis d'échéances longues. Mastercard s'est engagée en juin 2024 sur une tokenisation intégrale du commerce en ligne européen à l'horizon 2030. La saisie manuelle du numéro de carte et les codes à usage unique disparaîtraient au même terme. Visa a annoncé en 2024 son propre service de clés d'accès de paiement, adossé aux spécifications FIDO. Aucune de ces annonces ne crée d'obligation. Elles renseignent en revanche sur l'affectation des investissements des réseaux, donc sur les fonctions nouvelles qui apparaîtront d'abord, et sur les émetteurs qui les serviront en premier.

Clés d'accès et FIDO, ce qui vaut possession et ce qui vaut inhérence

Une clé d'accès est une paire de clés cryptographiques créée par un authentificateur pour un site précis et pour un compte précis. Elle est décrite par WebAuthn, spécification publiée par le W3C, que la FIDO Alliance réunit avec ses propres spécifications sous le nom de FIDO2. La clé privée reste dans l'authentificateur, élément sécurisé du téléphone, module de plateforme de l'ordinateur ou clé physique branchée. Elle n'est jamais transmise au site, et une clé liée à l'appareil ne quitte pas le matériel qui l'a créée. Le site n'enregistre que la clé publique, l'identifiant de la clé d'accès et quelques métadonnées. À chaque authentification, l'authentificateur signe un défi fourni par le site, accompagné de l'origine appelante et d'un jeu de drapeaux d'état. Le serveur vérifie cette signature avec la clé publique conservée depuis l'enrôlement.

La résistance à l'hameçonnage procède de la vérification du domaine appelant, opérée par le navigateur puis par le serveur. Chaque clé d'accès porte un identifiant de partie de confiance, qui est un nom de domaine. Le navigateur refuse de présenter la clé à une page dont le domaine ne correspond pas, et il inclut l'origine réelle dans les données signées. Le serveur compare ensuite cette origine à celle qu'il attend. La comparaison échoue dès qu'un attaquant relaie la cérémonie depuis un domaine tiers, quelle que soit la ressemblance de ce domaine avec le domaine légitime. L'omission de cette comparaison supprime la propriété qui justifiait le passage à FIDO, le dispositif se réduisant alors à une vérification biométrique sans garantie d'origine.

Les clés d'accès se répartissent en deux catégories selon leur mode de conservation. Une clé synchronisée est sauvegardée dans le trousseau du fournisseur de plateforme, et elle suit le compte de l'utilisateur d'un appareil à l'autre. Une clé liée à l'appareil ne quitte jamais le matériel qui l'a créée. La spécification WebAuthn expose cette distinction au serveur par deux drapeaux, l'éligibilité à la sauvegarde et l'état de sauvegarde courant. Ces deux drapeaux parviennent au serveur dès l'enrôlement. Un émetteur qui exige un facteur de possession attaché à un appareil dispose donc du moyen d'écarter les clés synchronisées avant tout paiement.

L'indépendance des éléments est régie par l'article 9 du même règlement délégué. Le texte admet que les deux facteurs transitent par un appareil multifonction, à condition que des mesures d'atténuation empêchent la compromission de l'un d'emporter l'autre, dont des environnements d'exécution sécurisés séparés. Une clé privée logée dans l'élément sécurisé, déverrouillée par une comparaison biométrique traitée dans ce même environnement, répond directement à cette exigence. Le dossier de conformité décrit donc l'architecture matérielle du dispositif, environnement par environnement, en indiquant ce qui sépare le traitement biométrique du stockage de la clé. La dénomination commerciale de l'authentificateur n'apporte aucune information sur cette séparation.

L'enrôlement est la cérémonie au cours de laquelle une clé d'accès est créée puis enregistrée par l'émetteur. Il comporte trois temps. Le premier crée la clé au cours d'une session déjà authentifiée. L'occasion la plus courante est un défi 3-D Secure servi depuis le domaine du serveur de contrôle d'accès, ou bien une session ouverte dans l'application bancaire. Le deuxième temps enregistre la clé publique, l'identifiant de la clé, l'identifiant de modèle de l'authentificateur et les drapeaux de sauvegarde. Cet identifiant de modèle se résout auprès du service de métadonnées de la FIDO Alliance, qui publie les caractéristiques déclarées des familles d'authentificateurs enregistrées auprès de lui. Ce service autorise l'exclusion d'un modèle dont la faiblesse serait connue. Toutes les familles n'y sont pas enregistrées, et un identifiant inconnu de ce service ne vaut donc pas défaut. Le troisième temps organise le cycle de vie, avec la révocation, le changement d'appareil et le chemin de repli prévu quand aucune clé n'est disponible.

• Exiger la vérification de l'utilisateur et la contrôler côté serveur. La requête n'engage que le client, qui reste libre de l'ignorer ; seul le drapeau reçu dans l'assertion établit qu'un second facteur a été présenté.
• Stocker l'identifiant de modèle de l'authentificateur. Il permet de savoir, après coup, quelle famille de matériel a produit la clé, et de retirer un modèle dont une faiblesse serait publiée.
• Décider par écrit du sort des clés synchronisées. Acceptées pour l'ouverture de session, refusées pour le paiement, ou acceptées partout, la règle doit exister avant le premier enrôlement.
• Notifier chaque ajout de clé sur un canal distinct. Un enrôlement frauduleux est plus rentable pour l'attaquant qu'une interception, et il ne laisse aucune trace visible par le porteur.
• Conserver un chemin de repli documenté. Perte d'appareil, réinitialisation, achat depuis un ordinateur partagé : ces cas existent, et le repli qui les traite fixe le niveau de sécurité réel du dispositif.
• Vérifier l'origine appelante à chaque assertion. Sans ce contrôle, la résistance à l'hameçonnage disparaît, et le dispositif ne vaut plus qu'un mot de passe biométrique.

La délégation d'authentification, qui authentifie et qui répond

La délégation d'authentification désigne l'exécution de la cérémonie d'authentification forte par un tiers, pour le compte de l'émetteur qui en porte l'obligation. Cette obligation est posée par l'article 97 de la DSP2, qui désigne l'émetteur sans préciser qui exécute matériellement la cérémonie. Le tiers peut être un commerçant, un portefeuille ou un prestataire spécialisé, lié à l'émetteur par un accord d'externalisation. La responsabilité ne se transfère pas pour autant, et l'Autorité bancaire européenne le rappelle dans son avis de juin 2019 comme dans ses orientations sur l'externalisation. Le superviseur demande donc des comptes à l'émetteur, y compris pour les cérémonies exécutées par le tiers.

Trois configurations coexistent sur le marché, et chacune répartit autrement les engagements contractuels. Un commerçant authentifie son propre client déjà connecté, avec la clé d'accès que ce client emploie pour ouvrir sa session. Un portefeuille authentifie le porteur sur l'appareil, ce que font Apple Pay et Google Pay depuis leur origine. Un prestataire d'authentification opère pour un ensemble de commerçants, au titre d'un programme de réseau qui l'agrée et le surveille. Les deux premières supposent un accord bilatéral. La troisième se contractualise par l'adhésion au programme, sans relation directe entre le commerçant et chaque émetteur, ce qui la rend praticable pour un marchand multi-pays.

Les deux grands réseaux publient chacun leur programme de délégation. Visa opère un programme de délégation de l'authentification, Mastercard décline le sien sous ses marques d'authentification du porteur, et certains schémas domestiques en proposent également. Les conditions d'éligibilité tiennent en général à un volume, à un taux de fraude tenu dans la durée, et à l'emploi d'une authentification conforme aux spécifications FIDO. Les barèmes exacts ne sont pas publics. La comparaison entre programmes reste donc impossible sans passer par un acquéreur. L'accès de celui-ci aux règles de réseau détermine l'information dont le commerçant disposera, ce qui en fait un critère de choix de l'acquéreur lui-même.

Le gain attendu de la délégation porte sur un point unique, la suppression du défi servi par l'émetteur au milieu du tunnel de paiement. Un commerçant qui authentifie déjà son client à l'ouverture de session réutilise cette cérémonie au lieu d'en imposer une seconde quelques secondes plus tard. La condition est exigeante, parce que la cérémonie d'ouverture de session doit elle-même satisfaire l'authentification forte, avec deux éléments indépendants et un lien dynamique au montant et au bénéficiaire. La preuve doit ensuite voyager jusqu'au message d'autorisation. L'émetteur qui ne la voit pas oppose un refus réversible réclamant la SCA, alors que la cérémonie a bien eu lieu. Un mot de passe suivi d'un lien envoyé par courriel ne remplit aucune de ces deux conditions. Le filtre ainsi posé écarte la plupart des candidats à la délégation.

Secure Payment Confirmation et l'authentification dans le navigateur

Secure Payment Confirmation est une spécification du W3C, développée par son groupe de travail sur les paiements web. Elle organise l'authentification d'un payeur par clé d'accès au cours d'un paiement en ligne, et n'ajoute à WebAuthn que deux fonctions. La première est l'appel d'une clé d'accès depuis une origine autre que celle qui l'a créée, opération que WebAuthn interdit par construction. La seconde est une fenêtre de confirmation dessinée par le navigateur, qui affiche le bénéficiaire, le montant et l'instrument avant que l'utilisateur ne valide. Ces deux ajouts répondent à des besoins de paiement que WebAuthn seul ne couvrait pas.

La seconde fonction produit une conséquence réglementaire. Les données client signées par l'authentificateur contiennent un objet de paiement, où figurent le bénéficiaire, l'origine appelante, le montant et l'instrument choisi. La signature couvre donc la transaction elle-même, et pas seulement un défi aléatoire. L'exigence de lien dynamique posée par l'article 5 du règlement délégué se trouve remplie par la construction du protocole. Une assertion WebAuthn ordinaire ne transporte pas ces données, et l'émetteur qui veut démontrer le lien dynamique doit alors les rattacher lui-même à la cérémonie. Le protocole dispense l'émetteur de ce travail, et la même assertion vaut preuve d'authentification et preuve du lien dynamique.

L'emploi de Secure Payment Confirmation suppose un enrôlement préalable. La clé d'accès doit avoir été créée pour le domaine de l'émetteur ou du réseau, ce qui suppose un moment où ce domaine s'exécute dans le navigateur du porteur. Le défi 3-D Secure remplit cette fonction, puisqu'il est servi depuis le domaine du serveur de contrôle d'accès. L'enrôlement depuis un cadre incorporé à une page tierce reste possible, à condition que cette page hôte accorde explicitement, par une politique de permissions, le droit de créer une clé destinée au paiement. En l'absence d'enrôlement, le commerçant ne dispose d'aucune clé à invoquer et le parcours retombe sur le défi classique. Le serveur de contrôle d'accès doit ensuite savoir vérifier une assertion de ce type. Cette capacité reste loin d'être acquise chez tous les fournisseurs.

La décision d'implémenter Secure Payment Confirmation repose sur deux mesures internes préalables. La première porte sur la part du trafic éligible, relevée navigateur par navigateur et système par système. La seconde porte, sur cette part seulement, sur le taux d'abandon du défi actuel, seul chiffre qui donne au projet une valeur économique. Aucun repère public comparable n'existe sur ce taux, chaque prestataire publiant le sien avec sa propre définition du dénominateur. La mesure interne reste donc la seule base de décision vérifiable, et sa production demande quelques jours.

EMV 3DS 2.3 et l'après, ce qu'un marchand peut demander aujourd'hui

EMV 3-D Secure est le protocole de messages par lequel un commerçant demande à l'émetteur d'authentifier le porteur au cours d'un paiement à distance, et par lequel l'émetteur répond. EMVCo en publie la spécification et en fait évoluer les versions. La version 2.3 ne crée pas l'authentification par clé d'accès. Les données FIDO circulent dans les messages 3-D Secure depuis la version 2.1.0, publiée en 2017. EMVCo en a publié le guide d'emploi le 28 octobre 2020. Ce guide définit un jeu de données d'attestation d'authentificateur, qui décrit l'appareil sans porter d'information identifiant la personne. La version 2.3.1, publiée en 2022, ajoute la liaison d'appareil et l'enchaînement automatisé des bascules hors bande entre application marchande et application bancaire. Le support de Secure Payment Confirmation y progresse.

Les indicateurs de préférence du demandeur sont les champs par lesquels le commerçant porte sa stratégie d'exemption et de délégation. La version 2.2 en a étendu la liste pour couvrir les cas ouverts par la réglementation européenne. L'analyse de risque déjà effectuée et l'authentification forte déjà réalisée en amont y figurent. Ces valeurs ne contraignent pas l'émetteur, qui reste libre d'imposer un défi malgré tout. Elles portent à sa connaissance ce que le commerçant a exécuté et le traitement qu'il souhaite. La même version 2.2 a introduit l'authentification découplée, où l'émetteur valide le porteur en dehors du tunnel marchand. Ce mode ouvre les parcours sans navigateur et les paiements confirmés depuis l'application bancaire. La correspondance exacte entre chaque valeur et chaque cas d'usage dépend de la version implémentée, et figure dans la documentation du prestataire.

Le prix se répartit sur trois lignes distinctes, dont la première est la moins coûteuse. L'authentification 3-D Secure se facture à l'unité par le prestataire, sur une assiette qui varie selon les contrats, chaque demande transmise ou chaque défi effectivement servi. La délégation ajoute le coût d'un fournisseur d'authentification et celui de l'adhésion au programme du réseau. La ligne la plus lourde est la maintenance des chemins de repli. Elle n'apparaît dans aucun barème. Aucune négociation avec le prestataire ne porte sur elle. Chaque parcours ajouté doit être testé, mesuré et corrigé, pour une population qui rétrécit à mesure que les clés d'accès se généralisent.