Directive DSP2: l'avis de l'ABE offre plus de temps pour implémenter une authentification forte client

Frederik Mennes, juillet 10, 2019

Le 21 juin 2019, l'Autorité bancaire européenne(ABE)a publié un avis sur l'authentification des clients (SCA) dans le cadre de la directive révisée sur les services de paiement(PSD2). L'avis de l'ABE permet aux autorités compétentes (CA) d'accorder exceptionnellement du temps supplémentaire au-delà du 14 septembre 2019 à des fournisseurs de services de paiement (PSP) spécifiques pour se conformer aux exigences de l'ACS. Il fournit également des éclaircissements sur la conformité des méthodes d'authentification communes avec les exigences SCA de PSD2.

Dans cet article, je discute des clarifications de l'avis de l'ABE et soulève également certains domaines où des éclaircissements supplémentaires sont nécessaires.

Portée de l'extension

L'avis permet aux autorités compétentes (CA) d'accorder exceptionnellement du temps supplémentaire au-delà du 14 septembre 2019 à des fournisseurs de services de paiement (PSP) spécifiques pour se conformer aux exigences de l'ACS. Plus précisément, l'avis indique que « les CA peuvent décider de travailler avec les PSP et les parties prenantes concernées, y compris les consommateurs et les commerçants, afin de prévoir un délai supplémentaire limité pour permettre aux émetteurs de migrer vers desapproches d'authentification conformes à la SCA, comme celles décrites dans le présent avis, et avec les acquéreurs de migrer leurs marchands vers des solutions qui soutiennent SCA.»

À ce titre, l'Opinion fait fortement référence aux émetteurs, aux acquéreurs et aux commerçants lorsqu'ils discutent de la possibilité d'obtenir plus de temps pour se conformer. Cette terminologie est généralement utilisée dans le contexte du paiement par carte pour le commerce électronique. C'est probablement le cas parce que la plupart des demandes de report de la date limite de septembre provenaient d'entreprises de commerce électronique.

Cela soulève la question de savoir si les autorités compétentes n'accorderont que du temps supplémentaire dans le contexte des paiements par carte pour le commerce électronique, et peut-être pas dans le contexte d'autres applications qui nécessitent une authentification forte, telles que les services bancaires en ligne et mobiles Bancaire. Nous avons demandé à l'ABE de clarifier cette question.

Activation de la surveillance des fraudes conforme à PSD2 avec OneSpan Risk Analytics
PAPIER BLANC

Activation de la surveillance des fraudes conforme à PSD2 avec OneSpan Risk Analytics

Les nouvelles exigences PSD2 exigent que les organisations de services financiers effectuent une surveillance des transactions. Découvrez les exigences spécifiques et la manière dont OneSpan Risk Analytics peut vous garantir la conformité dans ce livre blanc.

Télécharger

Calendrier de l'extension

Comme mentionné ci-dessus, l'avis permet aux CA d'accorder «un délai supplémentaire limité» aux PSP pour se conformer aux exigences de l'ACS. Toutefois, l'avis n'impose pas de délai. Par conséquent, les différents PSP peuvent avoir des échéanciers différents pour se conformer aux exigences de l'ACS, ce qui pourrait avoir une incidence sur les paiements lorsque plusieurs PSP sont impliqués. Par exemple, si un paiement par carte est effectué entre un émetteur de carte qui se conforme à partir du 14 septembre 2019 et un acquéreur qui a reçu une prolongation de six mois, l'acquéreur peut envoyer une demande de paiement sans SCA à l'émetteur. Mais, l'émetteur va refuser le paiement, car il nécessite SCA. Par conséquent, les paiements pourraient être refusés, bien que l'émetteur et l'acquéreur agissent correctement. Cela soulève clairement la nécessité pour les CA d'accorder des prolongations de manière coordonnée.

Alignement des calendriers SCA et Open Banking

Jusqu'à présent, l'introduction des API et des API bancaires ouverts et de l'ACS allait de pair et suivait le même calendrier, la date limite étant le 14 septembre 2019 pour les deux. L'avis de l'ABE accorde un délai supplémentaire pour mettre en œuvre les exigences de l'ACS, mais ne dispose pas de temps supplémentaire pour mettre en œuvre les API Open Banking, l'autre pilier de PSD2. Par conséquent, les banques pourraient offrir des API bancaires ouvertes à des fournisseurs tiers (TPP) sans SCA.

Cela a un certain nombre de conséquences :

  • Impact sur la sécurité : Si une banque ne protège pas les comptes bancaires avec SCA, et si elle prend en charge l'authentification via le modèle intégré, les TPP obtiendront des informations d'identification faibles utilisées pour protéger les comptes bancaires. Par exemple, si un compte bancaire est protégé par un nom d'utilisateur et un mot de passe statique, le PTP pourrait obtenir ces informations d'identification. Par conséquent, le PTP pourrait se connecter à ces comptes bancaires et peut-être effectuer des paiements sans que les titulaires de compte en soient conscients.
  • Impact sur l'expérience utilisateur : Les utilisateurs qui accèdent à leurs comptes bancaires par l'intermédiaire d'un PTP (ou plus précisément d'un fournisseur de services d'information sur les comptes ou d'un AISP) peuvent être tenus d'effectuer des SCA pour la Banque A, mais pas pour la Banque-B. Par conséquent, l'expérience utilisateur au sein de l'application de l'AISP sera différente pour les différentes banques, ce qui pourrait prêter à confusion. Cela s'applique également aux TPP qui agissent à titre de fournisseur de services d'initiation aux paiements (PISP).
Webcast

Webinaire : PsD2 Strong Customer Authentication Deadline Extension - Clarifications sur l'avis de l'ABE

Apprenez de Frederik Mennes, expert de PSD2 SCA, sur la portée et les délais de l'extension SCA et sur les solutions d'authentification qui se conforment.

Regarder

 Conformité des éléments d'authentification

Les normes techniques réglementaires (RTS) sur l'authentification client forte et la communication commune et sécurisée de PSD2 définissent SCA comme une «authentification basée sur l'utilisation de deux ou plusieurs éléments classés comme la connaissance (quelque chose que seul l'utilisateur sait), la possession (quelque chose que seul l'utilisateur possède) et l'inhérence (quelque chose que l'utilisateur est) qui sont indépendants [...]». L'avis contient des précisions sur les éléments d'authentification qui peuvent être considérés comme forts et dans quelle catégorie ils tombent (c.-à-d. connaissance, possession ou inhérence).

Voici un certain nombre de précisions dignes de mention de l'avis :

  • SMS comme élément de possession: L'avis précise que le SGS peut être considéré comme un élément de possession valide. Plus précisément, la carte SIM dans l'appareil mobile qui reçoit le SMS est un élément de possession valide. Cela implique que les mots de passe ponctuels (OTP) livrés par SMS peuvent être utilisés pour construire un mécanisme d'authentification fort lorsqu'ils sont combinés avec un deuxième facteur (par exemple un mot de passe ou un NIP). Toutefois, l'avis ne précise pas si les SMS peuvent être utilisés pour des liaisons dynamiques. En effet, l'exigence de liaison dynamique à l'article 5 de la RTS stipule que la confidentialité et l'intégrité des informations de paiement (par exemple, numéro de compte bancaire ou montant d'argent) doivent être protégées pendant le processus d'authentification. Étant donné que le contenu d'un SMS n'est généralement pas protégé, il semble que SMS ne répond pas aux exigences de liaison dynamique. L'ABE devrait apporter d'autres précisions à ce sujet.
  • Applications mobiles comme élément de possession : L'avis renforce l'article 7 de la RTS, qui implique que les applications mobiles sont des éléments de possession valides, si elles sont protégées par un mécanisme de liaison de périphérique qui relie l'application mobile à l'appareil sur lequel elle s'exécute. Une application mobile qui n'est pas protégée par un mécanisme de liaison d'appareil ne peut pas être considérée comme un élément de possession valide.
  • Listes OTP comme élément de possession: Les institutions financières utilisent parfois des cartes matricielles imprimées ou des listes de PDO imprimées (parfois appelées « listes TAN ») pour authentifier l'utilisateur final d'une application bancaire en ligne. L'avis précise que ces cartes imprimées ou listes ne constituent pas un élément de possession valide, car elles peuvent facilement être copiées (par exemple, en prenant une photo de la carte à l'aide d'un appareil mobile).

Il y a un certain nombre de sujets qui ne sont pas abordés dans l'avis et qui bénéficieraient d'éclaircissements supplémentaires. J'ai soumis des questions sur ces sujets via l'outil de questions-réponses de l'ABE:

  • Utilisation d'IBAN partiels ou complets dans les liaisons dynamiques : L'exigence de liaison dynamique stipule que le code d'authentification doit être calculé sur un identifiant du bénéficiaire. Supposons qu'un IBAN soit utilisé pour identifier un bénéficiaire. Est-il alors nécessaire de calculer le code d'authentification sur l'IBAN complet, ou suffit-il d'utiliser une partie de celui-ci? De même, est-il suffisant de ne montrer qu'une partie de l'IBAN au payeur? Dans la pratique, les banques n'utilisent souvent qu'une partie de l'IBAN pour de multiples raisons, car il est gênant de taper ou de montrer l'IBAN complet.
  • Utilisation du hon des informations de paiement : Toujours dans le contexte d'un lien dynamique, la question est souvent posée de savoir s'il est nécessaire de calculer le code d'authentification sur les informations de paiement (montant, ID du bénéficiaire) elle-même, ou s'il suffit de calculer le code d'authentification sur un haussier des informations de paiement. Si le code d'authentification est calculé sur une valeur de haussier et que le payeur ne voit pas quelles informations de paiement sont utilisées, les payeurs peuvent ne pas comprendre à quelle transaction ils s'engagent réellement. Les attaques d'ingénierie sociale contre les systèmes d'authentification l'exploitent souvent.

Nous espérons que l'ABE apportera des éclaircissements supplémentaires sur ces sujets.

Une analyse plus approfondie des exigences SCA de PSD2 est disponible sur mon blog.

Cet article, initialement publié le 2 juillet 2019, est apparu pour la première fois sur la page personnelle LinkedIn de Frederik Mennes et le blog Wordpress.

 

Frederik dirige le Security Competence Center de OneSpan, où il est responsable des aspects de sécurité des produits et de l'infrastructure de OneSpan. Il possède une connaissance approfondie des technologies d'authentification, de gestion des identités, de réglementation et de sécurité pour les applications cloud et mobiles.