L'authentification transactionnelle consiste à valider l'opération elle-même, et non l'ouverture de session qui la précède. La distinction n'est pas théorique : entre le moment où un utilisateur s'authentifie et le moment où un virement part, il peut s'écouler des heures, et beaucoup de choses peuvent arriver à la session. Authentifier la porte ne protège pas ce qui se passe dans la pièce.
Ce que la session ne peut pas garantir
Une authentification réussie produit un jeton. Ce jeton fait ensuite autorité pour toutes les requêtes, sans distinction de gravité : consulter un solde et modifier un IBAN présentent la même preuve d'identité.
Trois scénarios exploitent cet écart :
- Le vol de jeton. Un cookie dérobé par malware ou capté lors d'une attaque en relais permet d'agir sans repasser par le moindre facteur. C'est le butin recherché par le phishing moderne.
- La session légitime détournée. Un poste non verrouillé, un accès distant compromis, une extension de navigateur malveillante : la session est authentique, l'opérateur ne l'est pas.
- La manipulation de l'utilisateur. L'utilisateur agit lui-même, mais sous influence — fraude au faux conseiller, instruction attribuée à un dirigeant, prétexte d'urgence. La session est parfaitement légitime, l'intention ne l'est pas.
Dans les trois cas, aucun contrôle portant sur la connexion ne détecte quoi que ce soit. Il faut déplacer le point de vérification vers l'acte.
Le lien dynamique : le principe posé par la DSP2
La DSP2 (directive (UE) 2015/2366) formule ce mécanisme avec précision pour les paiements électroniques. L'authentification forte du client doit y être assortie d'un lien dynamique : le code d'authentification doit être spécifique au montant et au bénéficiaire de l'opération, et toute modification de l'un ou de l'autre doit invalider ce code.
L'exigence est élégante, car elle traite le scénario où l'attaquant contrôle l'affichage : même s'il parvient à faire valider une opération, il ne peut pas en changer les paramètres après coup sans faire échouer la validation.
Deux notions voisines complètent le tableau :
- Ce que vous voyez est ce que vous signez : l'utilisateur doit visualiser les éléments réels de l'opération au moment de la validation, sur un canal que l'attaquant ne contrôle pas.
- Non-répudiation : la validation doit produire une preuve exploitable ultérieurement, ce qui suppose une journalisation liant la preuve d'authentification et les paramètres de l'opération.
Quelles opérations mériteraient ce traitement
Le paiement n'est qu'un cas particulier. Le même raisonnement s'applique à toute action dont l'annulation est coûteuse, lente ou impossible.
| Opération | Impact si détournée | Éléments à lier à la preuve |
|---|---|---|
| Virement, changement d'IBAN | perte financière directe, récupération incertaine | montant, bénéficiaire, référence |
| Ajout d'un moyen d'authentification | prise de contrôle durable du compte | méthode ajoutée, appareil concerné |
| Création d'un compte à privilèges | accès à l'infrastructure | identité créée, niveau de droits |
| Modification d'une règle de messagerie | interception silencieuse des échanges | règle, destination de redirection |
| Export massif de données | violation de données, notification, sanction | volume, périmètre, destination |
| Signature d'un engagement contractuel | portée juridique | document, montant, contrepartie |
| Modification d'un bénéficiaire de paie | fraude interne difficile à détecter | salarié concerné, nouvelles coordonnées |
Une organisation qui n'instrumente que le paiement laisse ouvertes les autres lignes de ce tableau — dont plusieurs sont, pour un attaquant, plus rentables et moins surveillées.
Comment mettre en œuvre sans paralyser l'activité
- Sélectionner un petit nombre d'opérations à fort impact plutôt que d'instrumenter largement. Trois à cinq actions bien choisies couvrent l'essentiel du risque.
- Afficher les paramètres réels au moment de la validation, sur un canal distinct de celui où l'opération est saisie. C'est ce qui neutralise l'attaquant qui contrôle l'écran.
- Lier cryptographiquement la preuve aux paramètres, de sorte qu'une modification invalide la validation.
- Journaliser l'ensemble : preuve, paramètres, horodatage, contexte. Sans cela, aucune non-répudiation.
- Choisir un facteur non relayable. Une validation par code recopié se relaie ; une validation par simple bouton d'approbation se provoque. L'exigence est ici plus forte que pour une simple connexion.
Ce dernier point est décisif, et c'est l'apport direct du facteur cognitif : le challenge est présenté au moment de l'action, dans un canal éphémère ouvert par un QR code dynamique à usage unique, et sa résolution suppose une méthode personnelle acquise lors d'un enrôlement hors ligne. Il n'existe ni valeur à intercepter ni geste réflexe à déclencher — y compris lorsque l'utilisateur est au téléphone avec un faux conseiller.
Le lien avec le Zero Trust
Une architecture Zero Trust évalue chaque requête, mais elle l'évalue à partir d'un jeton émis plus tôt. L'authentification transactionnelle apporte le signal frais qui manque : une preuve contemporaine de l'acte, et rattachée à ses paramètres. C'est le complément naturel du step-up, qui décide du moment où élever, là où l'authentification transactionnelle définit ce qui est prouvé.
FAQ
Est-ce la même chose que le step-up ?
Non, mais les deux se combinent. Le step-up élève le niveau d'exigence à un moment donné. L'authentification transactionnelle précise ce qui est prouvé : non pas une identité, mais l'accord explicite sur une opération et ses paramètres.
Le lien dynamique est-il obligatoire hors paiement ?
La DSP2 l'impose pour les paiements électroniques relevant de son champ. Hors de ce périmètre, aucune obligation générale n'existe, mais le principe reste la meilleure protection connue contre la manipulation d'une opération en cours.
Cela n'alourdit-il pas trop les parcours ?
Seulement si le mécanisme est appliqué partout. Réservé à un petit nombre d'actions à fort impact, il est bien accepté : l'utilisateur comprend pourquoi un virement demande davantage qu'une consultation de solde.
Que faire des opérations réalisées par des automates ?
Elles relèvent d'un autre régime : identités techniques, portée restreinte, secrets à rotation automatique, contrôles de cohérence et plafonds. Une validation humaine reste néanmoins pertinente sur les seuils les plus élevés.
Aller plus loin : le facteur cognitif au moment de l'action · step-up authentication · fraude au faux conseiller · obligations NIS2, DORA, DSP2 et CRA