Les défis bancaires s'additionnent : PSD2 signifie de nouvelles règles de partage de données

Publié: 2018-04-13

Beaucoup d'entre vous ont sans doute entendu parler de la directive de l'Autorité bancaire européenne (ou EBA) de l'Union européenne appelée PSD2 (abréviation de Payment Services Directive). Ces lignes directrices ont été initialement publiées fin 2015. En janvier 2018, tous les États membres étaient tenus de mettre en œuvre la réglementation.

Le secteur bancaire est confronté à de nombreux défis s'il ne pense pas déjà à un avenir très numérique.

Comprendre l'authentification client forte pour le PSD2 de l'UE

Les principaux objectifs de PSD2 incluent :

  1. Ouvrir de nouvelles opportunités de marché pour une variété d'acteurs tels que les commerçants en ligne, tout en uniformisant les règles du jeu pour toutes les parties prenantes clés
  2. Assurer la transparence du consommateur et le choix du consommateur
  3. Introduire de nouvelles pratiques de sécurité plus robustes pour les paiements en ligne

Il existe un certain nombre de lignes directrices générales pour PSD2 ; cependant, l'une des meilleures directives PSD2 peut être téléchargée à partir du MEF (Mobile Ecosystem Forum).

Authentification client forte

L'un des éléments clés de la réglementation PSD2 est le concept d'authentification forte du client (ou SCA). L'ABE note : « Grâce à PSD2, les consommateurs seront mieux protégés lorsqu'ils effectueront des paiements ou des transactions électroniques (comme l'utilisation de leur banque en ligne ou l'achat en ligne).

La norme technique de réglementation (RTS) fait de l'authentification forte du client (SCA) la base pour accéder à son compte de paiement, ainsi que pour effectuer des paiements en ligne. En bref, SCA exige, au minimum, une authentification à deux facteurs (2FA).

L'authentification à deux facteurs signifie que les utilisateurs devront "prouver" leur identité par deux éléments distincts sur trois :

  1. Quelque chose qu'ils connaissent (un code PIN ou un mot de passe)
  2. Quelque chose qu'ils possèdent (un appareil mobile, une carte)
  3. Quelque chose qu'ils sont (empreintes digitales, scan du visage : par exemple, biométrie)

L'ABE note que la SCA est couramment utilisée dans toute l'UE ; cependant, ce n'est pas toujours le cas pour les transactions de paiement en ligne telles qu'un paiement par carte de crédit ou un virement bancaire direct. SCA est appliqué dans les pays de l'UE que sont la Belgique, les Pays-Bas et la Suède) ; cependant, dans d'autres pays de l'UE, la SCA n'est appliquée que sur une base volontaire, selon un excellent communiqué de presse de la Commission européenne.

Alors que les États membres de l'UE devaient avoir mis en œuvre la PSD2 d'ici janvier 2018, la SCA deviendra obligatoire 18 mois plus tard après la norme technique de réglementation (RTS) de l'ABE après la date d'entrée en vigueur de la RTS (qui devrait être plus tard cette année) . Donc, pour l'essentiel, nous envisageons la mi-fin 2019 (septembre 2019 était l'une de ces dates citées par certains documents). Cela laissera suffisamment de temps à toutes les parties prenantes pour intégrer la SCA et d'autres exigences de sécurité dans leurs systèmes et flux de travail.

Banque de détail : Lions et banquiers et fintechs, oh mon Dieu !

retail_banking_fintech.jpg Les Fintechs menacent le statu quo. Contrairement aux banques, elles ne sont pas gênées par l'héritage, les réglementations et, dans la plupart des cas, même le besoin de gagner de l'argent. Les banquiers de détail doivent s'adapter et se concentrer sur la relation client pour rester compétitifs.

2FA pour SCA

Compte tenu du calendrier SCA, 2018 est le moment idéal pour les entreprises de commencer à mettre en œuvre des solutions 2FA pour tenir compte de la sécurité accrue requise.

Le cabinet d'avocats international Taylor Wessing, dans son article : Strong customer authentication under PSD2 , note que « l'ABE a convenu avec la majorité des répondants au document de consultation que, afin d'assurer la neutralité technologique et de permettre le développement de , accessibles et innovants, il ne convient pas de définir plus avant les éléments d'authentification. Cela signifie que l'EBA ne précise pas la manière dont 2FA peut être mis en œuvre. Il existe une variété de schémas, y compris la livraison de jetons sur des canaux mobiles tels que les SMS ou les notifications push ou des canaux de courrier électronique plus traditionnels, ainsi que des solutions de jetons logiciels TOTP et autres.

Tout cela étant noté, nous devons souligner que, comme tout bon schéma de mise en œuvre de 2FA, il existe certaines limitations et réglementations spécifiques et celles-ci doivent être soigneusement prises en compte.

Codes d'authentification

La RTS note que la génération d'un code d'authentification répond aux conditions suivantes :

  1. Aucune information concernant la connaissance, la possession et l'héritage ne peut être dérivée de la divulgation du code d'authentification
  2. Il n'est pas possible de générer un nouveau code d'authentification basé sur la connaissance de tout autre code d'authentification généré précédemment
  3. Le code d'authentification ne peut pas être falsifié

De plus, le RTS stipule qu'il ne faut pas tenter plus de 5 tentatives d'authentification infructueuses dans la durée de vie du code et que le temps maximum d'inactivité du payeur ou de l'utilisateur après s'être authentifié pour accéder à son compte de paiement en ligne ne doit pas dépasser 5 minutes. .

Liaison dynamique de la transaction

Le RTS indique que les transactions électroniques à distance - essentiellement les paiements effectués sur Internet (que ce soit sur un appareil de bureau tel qu'un ordinateur portable ou un appareil mobile) doivent inclure des éléments qui "lient dynamiquement la transaction à un montant spécifique et à un bénéficiaire spécifique". La RTS considère qu'il s'agit d'une forme supplémentaire de SCA.

Pour cette exigence SCA, le montant de la transaction de paiement ainsi que le bénéficiaire (ou le commerçant) doivent être fournis à l'utilisateur au moment d'une transaction 2FA. En cas de changement de montant ou de bénéficiaire, un autre code d'authentification doit être généré (par exemple, « lier dynamiquement » ce code au nouveau bénéficiaire et/ou au nouveau montant du paiement). Un message SMS avec toutes les informations requises peut ressembler à l'image de droite : Le code de sécurité de 10 minutes, le nom du commerçant (ou du bénéficiaire) et le montant de la transaction.

Fait intéressant, un code d'authentification généré par une application tierce compatible TOTP telle que Google Authenticator est généré complètement séparément des informations de paiement/marchand et ne peut donc pas être lié dynamiquement.

Indépendance des canaux

Cette exigence est un peu délicate. Le RTS stipule que les « prestataires de services de paiement doivent adopter des mesures de sécurité, lorsque l'un des éléments d'authentification forte du client ou le code d'authentification lui-même est utilisé via un dispositif polyvalent, pour atténuer le risque qui résulterait de ce dispositif polyvalent. être compromis. » Un appareil polyvalent peut être un appareil mobile ou une tablette, voire un ordinateur portable.

Si un utilisateur utilise un ordinateur portable et qu'il lui est demandé d'effectuer un paiement, ce commerçant peut envoyer un SMS à l'appareil mobile de l'utilisateur avec le bénéficiaire (par exemple, le commerçant) ainsi que le montant qu'il va payer, ainsi que l'authentification code dans le corps du SMS.

Dans un autre exemple, si l'utilisateur utilise un appareil mobile pour interagir avec un commerçant et initie un paiement, alors cette indépendance de canal n'interdit pas spécifiquement les SMS ou tout canal de livraison spécifique au mobile. Ici, c'est une ligne fine. Dans de nombreux cas, le seul appareil dont dispose un utilisateur est un appareil polyvalent tel qu'un téléphone portable. Mais, l'indépendance du canal n'est que cela - un canal indépendant sur le même appareil - un SMS avec un code d'authentification est un canal différent (en fait, c'est un canal hors bande , atteint via le numéro de téléphone mobile) que le mobile l'application ou le navigateur Web que l'utilisateur utilise avec le marchand. La même indépendance de canal s'appliquerait à l'utilisation d'une application mobile pour générer un code compatible TOTP (tel que Google Authenticator), mais comme indiqué précédemment, le code de plainte TOTP échoue à la liaison dynamique de la transaction.

À l'inverse, si l'utilisateur utilisait une application mobile pour accéder au marchand, une notification push à cette même application (avec le code d'authentification) ne serait pas possible, car il s'agit du même canal.

Il y a ceux qui diraient que 2FA sur SMS est très peu sécurisé et dans certains cas, cela pourrait être vrai. Oui, il y a eu des cas isolés où un attaquant a réussi à accéder aux messages SMS 2FA via SS7 sur un opérateur ; cependant, bon nombre de ces vulnérabilités ont été fermées. De plus, la manière dont le code d'authentification est généré et fourni à l'utilisateur et la manière dont le fournisseur de services de messagerie délivre ces codes est très importante.

Dans les situations où les appareils polyvalents sont répandus (et aujourd'hui, ce sont et continueront d'être les appareils les plus répandus), un canal de messagerie fourni par un opérateur mobile devrait continuer à être un canal hors bande viable pour les jetons 2FA.

Pour une analyse plus détaillée, j'ai trouvé un article de blog informatif de Frederik Mennes qui fournit plus de détails sur les types de scénarios - en particulier pour les appareils polyvalents - qui doivent être conformes à PSD2 SCA.

PSD2 SCA ne doit pas être pris à la légère, mais de nombreuses solutions 2FA déjà mises en œuvre devraient fonctionner ; Cependant, nous savons également que de nombreux marchands en ligne ne proposent pas encore de solutions conformes à PSD2 SCA. Au moment d'écrire ces lignes, il reste encore suffisamment de temps pour intégrer la SCA dans les workflows de paiement.

SAP Authentication 365 est une solution qui fournit une solution cloud basée sur une API pour permettre aux entreprises de mettre en œuvre une SCA conforme à PSD2. Le service mobile SAP Authentication 365 est un service de bout en bout qui vous permet de mettre en œuvre un service d'authentification à deux facteurs (2FA) multicanal rapidement et en toute sécurité, avec une authentification adaptée à votre entreprise numérique.

Il aide à protéger l'identité et les données de vos clients d'entreprise en permettant l'authentification par SMS, e-mail, notifications push ou jetons logiciels TOTP. L'API REST de SAP simplifie la génération et l'authentification des codes de validation ou d'authentification et offre la flexibilité et les capacités nécessaires pour permettre la mise en œuvre d'une stratégie SCA conforme à PSD2.