L’authentification forte est l’une des mesures phares de la directive sur les services de paiement (DSP 2). Avant toute chose, pour comprendre les raisons de l’introduction de ce nouveau protocole, il est nécessaire de bien différencier l’identification de l’authentification. L’identification est un ensemble d’éléments qui permet de dire qui on est, par exemple par l’intermédiaire d’un login, un matricule, un document d’identité, etc., sans pour autant certifier notre identité réelle. Cette dernière étape relève de l’authentification (est-on réellement la personne que l’on annonce être ?).
Les exigences de renforcement de l’authentification sont intégrées dans la DSP 2 pour améliorer les techniques de lutte contre la fraude, notamment sur internet. L’application des exigences techniques (RTS) le 14 septembre 2019 oblige les institutions financières à se doter de systèmes intégrant l’identification d’un utilisateur couplée à son authentification forte (c’est-à-dire au moyen de deux facteurs d’authentification tels que prévus par les textes européens). En prévision des forts impacts de déploiement, l’UE laisse aux acteurs jusqu’en 2022 pour mettre en place les exigences d’authentification forte.
Les travaux ont déjà commencé et l’un des premiers signes d’intégration de l’authentification forte dans les transactions en ligne est la disparition du fameux SMS (3D Secure), dont le code de six à huit caractères est jugé insuffisamment sécurisé. La validation des opérations par des moyens simples (identifiant et un mot de passe, 3DS, etc.) est trop facilement sujette aux fraudes et à l’usurpation d’identité numérique et physique. Ainsi, en France en 2018, sur les 704 milliards d’euros de transactions par carte, 439 millions ont été impactés par des fraudes et 1,3 million de cartes ont été fraudées. Le renforcement de l’authentification des clients couplée à celle des appareils qu’ils utilisent pour effectuer des opérations en ligne est désormais indispensable. Cependant, malgré les promesses d’amélioration en termes de sécurité des dispositifs, l’implémentation de l’authentification forte constitue un défi technologique et organisationnel pour les acteurs impactés : e-commerçants, institutions financières et prestataires de services de paiement (PSP). Sa généralisation à l’ensemble des services en ligne pose des questions en termes d’utilisation des données personnelles.
Une mesure qui vise à renforcer la sécurité des paiements
Théoriquement, l’authentification permet d’assurer que la personne qui s’identifie est bien celle qui va accéder à un service en ligne (paiement, consultation, etc.). La DSP 2 définit l’authentification forte comme étant composée de deux facteurs d’authentification parmi les éléments suivants :
- ce que l’on sait : un mot de passe, une caractéristique personnelle (nom de la rue de votre enfance, sport préféré, etc.) ;
- ce que l'on possède : un smartphone, une tablette, une carte magnétique, un hard-token ;
- ce que l’on est : des éléments biométriques (empreintes digitales, rétiniennes, etc.) ;
- ce que l’on sait faire : un selfie dynamique ;
- où l’on se trouve : géolocalisation dans des lieux de confiance ;
- à quel moment on effectue l’action : accès aux services à des heures jugées « normales ».
Une implémentation technologique complexe
La mise en œuvre de l’authentification forte nécessite une remise à plat des systèmes de validation des transactions sur internet. Cela constitue un véritable casse-tête pour les DSI, qui doivent intégrer de nouvelles technologies ainsi que des processus de vérification limités dans le temps, tout en impliquant une forte réactivité des SI.
Le code à usage unique (ou One Time Password – OTP), très en vogue sur les applications bancaires, permet de générer, dans un espace client, un code utilisable pour une seule et unique opération, dans un laps de temps restreint, afin de valider une opération en ligne (ajout de RIB, confirmation de virement, etc.). L’authentification passe soit par la recopie de tout ou partie du code transmis (technique HOTP et TOTP), soit la validation d’une notification qui apparaît dans l’espace client (protocole swipe). Ces techniques d’authentification permettent de valider le fait que le client possède un appareil qui lui est propre, par exemple, le smartphone sur lequel est installée l’application bancaire. Cependant, cette technique requiert la capacité de synchroniser l’appareil du client avec le SI impacté et de générer des multiples codes à usage unique. L’une des limites d’utilisation de cette technique est que le client doit forcément disposer d’une couverture réseau.
Un autre protocole d’authentification consiste à collecter les données biométriques des utilisateurs pour valider une opération. Empreintes digitales, rétiniennes et vocales sont aujourd’hui régulièrement utilisées, notamment pour les déblocages des appareils (tablettes, smartphone). Cette technologie peut requérir un enregistrement préalable, le plus souvent auprès du fabricant de l’appareil. Ces données ne sont pas accessibles aux e-commerçants ou institutions financières, sauf s’ils en font expressément la demande auprès de leurs clients. Pour les obtenir, ils doivent repenser leurs parcours clients et se doter d’outils pour collecter et stocker ces informations. Si les données biométriques du client ne sont pas connues au préalable, il est possible d’authentifier « ce que l’on est » en utilisant la technique de la reconnaissance faciale. Les DSI doivent alors faire appel à des éditeurs spécialisés pour intégrer l’étape de la prise de photo dans les parcours clients et comparer les données avec une photo d’identité transmise au préalable (justificatif d’identité). De nombreux éditeurs proposent ce type de technologie. La capacité à la rendre dynamique, ce qui valide le facteur d’authentification « ce que l’on sait faire », est primordiale : cligner d’un œil, montrer un ou plusieurs doigts, se mettre de profil, parler, etc. Les algorithmes de reconnaissance se basent sur des points de contrôle (position des yeux, du nez, de la bouche, du menton) ainsi que des scénarios de vieillissement. Sur le sujet, l’une des initiatives les plus attendues en France est le développement du service national Alicem. Actuellement en phase de test depuis juin 2019, ce complément au service d’identification FranceConnect permettra de centraliser les données biométriques contenues dans les documents d’identité. Elles pourront être utilisées à des fins de reconnaissance faciale par les entreprises qui en feraient la demande pour authentifier les utilisateurs de leurs services. Le fonctionnement est simple : l’utilisateur s’inscrit depuis son smartphone, enregistre son passeport via la lecture de la puce NFC et valide dans le même temps l’authenticité du document. Via une technologie de reconnaissance faciale en API, l’utilisateur pourra s’authentifier et accéder à de nombreux services publics en ligne. À terme, cet outil pourrait être proposé en API comme son prédécesseur FranceConnect, qui dispose déjà de presque 14 millions d’utilisateurs.
Le défi majeur pour les acteurs financiers est de pouvoir rendre ces protocoles d’authentification agiles et rapides. Les briques fonctionnelles SI doivent être « API-sées » pour échanger simplement et quasi instantanément les informations nécessaires au protocole d’authentification forte. Pour les banques, dont les SI sont très importants, cette étape sera l’une des plus difficile à franchir. Les fonctions techniques sont très exposées mais elles ne sont pas les seules. L’authentification forte impacte aussi les fonctions commerciales et marketing via les parcours clients. L’expérience utilisateur doit rester rapide et simple pour inciter l’acte d’achat ou de consultation d’un service pour ne pas risquer de décourager l’utilisateur.
L’expérience utilisateur plus ou moins impactée en fonction des acteurs
Les consommateurs pourraient en effet être confrontés à un allongement de la durée du tunnel d’achat ou de consultation. La DSP 2 implique l’ajout de nouvelles étapes aux parcours existants (collecte d’informations, appel aux PSP, autorisation, etc.). En plus du coût financier pour les déploiements techniques, la mise en place de ces contrôles renforcés risque d’avoir un impact commercial sur l’expérience utilisateur.
Afin de limiter la surconsommation de protocoles de sécurité, la Directive autorise des dispenses à l’authentification forte ; l’une d’elles concerne le caractère systématique de l’authentification forte. Par exemple, pour les e-commerçants, les opérations inférieures à 30 euros ne seront pas soumises à des protocoles systématiques. En revanche, la multiplication de ces micro-opérations devra activer une demande d’authentification forte à partir de la cinquième occurrence. Quant aux institutions financières et aux prestataires de paiement, ils devraient être exonérés d’authentification forte pour des transactions inférieures à 100 euros. La différence peut paraître faible cependant elle favorise les marchands. Ces derniers vont chercher à réaliser le maximum de transactions sans authentifier les clients, ce qui est en contradiction avec l’obligation de vigilance des PSP et des banques. Ceux-ci ont intérêt à assurer les paiements tout en se prémunissant du risque de fraude.
Autre exemple de dispense qui favorise les e-commerçants : la définition des « bénéficiaires de confiance ». Un établissement commercial peut créer des listes blanches recensant les « bénéficiaires de confiance » à savoir les utilisateurs présentant un niveau de risque de fraude faible. Cette évaluation du risque et la définition des critères sont à la main de chaque acteur impliqué dans le processus d’achat ou d’utilisation d’un service en ligne. Pour autant, le e-commerce est avantagé par rapport aux institutions financières. Les e-commerçants collectent en effet des volumes de données bien plus importants que les banques… et sont équipés pour les analyser : comportement en ligne, historique, contenu du panier, géolocalisation, adresse IP, heure des achats, fréquence des achats, etc. Ces critères combinés ou pris isolément peuvent déclencher ou non le protocole d’identification forte, en fonction du niveau de risque présenté par la transaction et le client. Les institutions financières, en revanche, ne bénéficient pas d’autant de données et de façon aussi régulière. Ces dernières mettront sûrement plus de temps à établir leurs propres listes blanches.
Ce travail est invisible pour les consommateurs, mais reste hautement stratégique pour les banques et les prestataires de paiements qui se retrouvent dans une position d’équilibriste. Ils devront en effet travailler conjointement avec les sites marchands pour éviter de bloquer les achats ou d’allonger le processus de paiement, tout en diminuant le risque de fraude La prise en compte de l’évaluation du commerçant versus celle l’institution financière est le défi technique majeur de l’implémentation de l’authentification forte. De plus, cet échange d’information implique une prise de recul importante au niveau juridique. En effet, il ne faut pas oublier qu’on collecte et échange des données personnelles et donc protégées par le RGPD.
La gestion problématique des données personnelles
Le RGPD et la DSP 2 n’ont pas la même définition d’une donnée personnelle. La Directive les décrit comme étant des données de sécurité personnalisées et des données de paiement sensibles qui par définition servent à authentifier la personne et évaluer le risque de fraude. Pour le RGPD, ces données sont donc interprétées comme étant des données à caractère personnel et sont donc soumises à des mesures de protection strictes et très encadrées. Or les étapes fondamentales de la lutte contre la fraude – que sont la collecte, le traitement et la conservation des données – doivent être consenties lors de la réalisation d’une opération en ligne. En cas de refus du consentement, l’opération de paiement ne peut être réalisée par le prestataire de paiement. De manière plus générale, le possible partage des informations (notamment des scoring de fraude) entre les marchands, les prestataires de paiement ou les institutions financières risque d’entrer en contradiction avec les mesures de protection de la CNIL.
Enfin, la DSP 2 étant une directive, sa transposition au niveau national peut laisser place à des divergences d’interprétation entre les membres de l’Union européenne. Dans le cadre d’opérations ou le site marchand est situé dans un pays A et le prestataire de paiement dans un pays B, la sécurisation de l’échange d’information et les règles d’obtention du consentement du client peuvent être source de conflit juridique.
Adapter les business models
Les acteurs ont jusqu’à 2022 pour mettre en place les protocoles d’identification forte et résoudre les problématiques techniques, juridiques et commerciales engendrées par la DSP 2. Beaucoup de travaux ont déjà été lancés pour notamment « API-ser » les DSI, mettre en place des datalakes couplés à de l’intelligence artificielle, etc. Ces changements impliquent une nécessité d’adaptation des institutions financières et des business models : les établissements qui tireront leur épingle du jeu seront ceux qui capteront le mieux les données et qui auront le bon niveau de commissionnement sur ces flux. En effet, pour les institutions financières, la captation du flux implique une création de PNB. Elles doivent trouver le bon positionnement entre la gestion du risque de fraude et la proposition d’un service rapide et efficace aux e-commerçants.
