La directive Payment Services Directive révisée (PSD2) impose à l’industrie de la finance de renforcer la sécurité et d’autoriser l’intervention de prestataires tiers. Les normes techniques détaillées pour la PSD2 ont été rendues publiques. Bjørn Søland, expert technique chez Nexus Group, société spécialisée dans les identités et la sécurité, explique en quoi consistent ces nouvelles normes et comment s’y conformer.
La directive PSD2 vise à rendre plus sûrs les paiements aussi bien en ligne qu’en magasin, et à permettre aux usagers d’accéder à des solutions plus pratiques, innovantes et économiques, proposées par des prestataires de services de paiement. Le 27 novembre 2017, la Commission européenne a enfin rendu publiques les normes techniques RTS (Regulatory Technical Standards) pour la directive PSD2. Ces normes constituent l’implémentation technique de la PSD2, et leur application est prévue pour septembre 2019.
« Les RTS sont le fruit d’un long processus, par lequel la Commission européenne, les banques et les prestataires de services de paiement ont défini un ensemble de règles qui relèvent pleinement du bon sens en termes de sécurité. Même si ces normes ne sont pas parfaites, elles représentent clairement un pas dans la bonne direction en termes de réduction des risques, tout en stimulant la concurrence au sein du système bancaire européen, » explique Søland.
Voici en quoi consistent les RTS et comment s’y conformer :
- Pratiquement tous les paiements électroniques nécessitent une authentification à deux facteurs (2FA).
Søland : « Les seules exceptions concernent les paiements de faible montant et les cas particuliers, tels que les horodateurs. »
- Ce que l’on appelle le « screen-scraping » n’est plus autorisé.
Søland : « Le terme screen-scraping se réfère à une pratique courante consistant pour un utilisateur à confier ses identifiants de login à une tierce partie, laquelle peut alors se connecter au nom de l’utilisateur. Ce faisant, la tierce partie peut exploiter les informations présentées à l’utilisateur. »
Cette approche est simple à implémenter – mais pose différents problèmes : confier les identifiants d’un utilisateur à autrui est en principe explicitement interdit par le contrat liant la banque et l’utilisateur ; la banque n’est pas en mesure d’implémenter un système de détection des malware côté client, et il n’y a aucun moyen d’imposer des restrictions sur le type d’informations auxquelles la tierce partie est autorisée à accéder.
Søland : « La bonne approche consiste à s’appuyer sur des communications serveur-serveur convenablement sécurisées au niveau de l’authentification, ainsi que sur des interfaces de programmation (API) précisément définies. À long terme tout le monde en bénéficie – même les tierces parties qui pratiquent actuellement le screen-scraping. »
- Les banques doivent fournir des API à la stabilité éprouvée, et garantir le même niveau d’authentification qu’ils offrent à leurs propres clients.
Søland : « Selon les RTS, il semble clair que les tierces parties ont le droit de s’appuyer sur les mécanismes d’authentification des utilisateurs de la banque. Cela implique que les banques doivent offrir une authentification à deux facteurs, pour protéger non seulement leurs propres services, mais également les services des tierces parties. »
- Nécessité d’une expérience utilisateur non contraignante.
Søland : « Par définition, les RTS sont neutres aussi bien en termes de technologie que de business model, et les utilisateurs peuvent aisément passer d’une technologie à l’autre. De ce fait, les banques ne peuvent plus s’appuyer sur des plateformes d’authentification à usage unique, à la flexibilité limitée. Ces plateformes peuvent ne pas s’intégrer dans le nouvel environnement d’échanges, et, plus important, l’expérience utilisateur qu’elles procurent est trop contraignante. »
Søland recommande de s’appuyer plutôt sur des solutions dites hybrides, pouvant être utilisées pour accéder à des ressources hébergées aussi bien dans le cloud et sur le web qu’en local ; des solutions capables de prendre en charge différentes méthodes de login, et de permettre aux utilisateurs de passer de l’une à l’autre.
Søland : « Un exemple de ce type de solution est la plateforme d’authentification Hybrid Access Gateway, pouvant être exploitée parallèlement à l’appli d’authentification Nexus Personal Mobile ainsi qu’à de nombreuses autres méthodes de login conviviales. »