Forte authentification des clients dans l'UE

Ceci est le deuxième d'une série de posts en trois parties détaillant PSD2: Strong Customer Authentication dans l'UE (SCA).

Dans la première tranche de cette série en trois parties, nous avons introduit la directive de l'Union européenne sur l'Autorité bancaire européenne (EBA) appelée PSD2 (deuxième directive sur les services de paiement) et a défini certains des principes directeurs de l'authentification forte des clients.

En ce qui concerne SCA, l'EBA note: "Merci aux consommateurs PSD2 seront mieux protégés lorsqu'ils effectuent des paiements ou des transactions électroniques (comme utiliser leurs services bancaires en ligne ou acheter en ligne). Comme indiqué dans la Partie 1, la Norme technique réglementaire (RTS) fait de l'authentification forte du client la base pour accéder à son compte de paiement, ainsi que pour effectuer des paiements en ligne. "

Dans cet article, Nous explorerons les limites et les régulateurs du SCA que les implémenteurs doivent prendre en compte. D'abord, regardons les codes d'authentification qui sont générés. Souvenez-vous qu'il s'agit essentiellement d'une authentification à deux facteurs, ou 2FA

Le RTS décrit les conditions suivantes pour les codes d'authentification:

• Aucune information concernant la connaissance, la possession et l'héritage ne peut être déduite du code d'authentification. Cela signifie que si vous connaissez le code d'authentification, il n'y a aucun moyen de dériver un autre élément de connaissance (par exemple, un ID utilisateur), ce que l'utilisateur a en sa possession (par exemple, un téléphone mobile). ), ou héritage – aspects concernant les utilisateurs eux-mêmes, tels que la biométrie.

• Il n'est pas possible de générer un nouveau code d'authentification basé sur la connaissance de tout autre code d'authentification précédemment généré . Pour cette condition, étant donné tout code d'authentification, il n'y a aucun moyen de générer un nouveau code d'authentification en faisant référence à un ou plusieurs codes d'authentification précédents.

• Le code d'authentification ne peut pas être falsifié . L'implémenteur doit créer des codes d'authentification pour que les codes falsifiés ou falsifiés ne puissent être validés avec succès.

• Il ne doit pas y avoir plus de cinq tentatives d'authentification infructueuses dans le délai de vie du code. Chaque code généré aura un délai d'expiration ou "temps de vie". Ce temporisateur démarre immédiatement après la génération du code et inclut le délai de livraison. Une bonne règle générale est que le code devrait expirer dans 15 minutes ou moins. Certaines organisations prennent cela à 30 minutes ou une heure, mais cela peut être trop long. Si l'utilisateur tente d'authentifier avec le code et échoue cinq fois, un nouveau code doit être envoyé. Cela empêche tout type de tentative de force brute pour comprendre le code.

• La ​​durée maximale sans activité du payeur ou de l'utilisateur après authentification pour accéder à son compte de paiement en ligne ne doit pas dépasser 5 minutes . Il s'agit d'une minuterie d'inactivité standard et, bien que distincte du code d'authentification, elle commence une fois que l'utilisateur a été authentifié et n'exécute aucune activité.

Toutes ces conditions sont relativement standard pour la génération / validation du code d'authentification. utilisé dans les situations 2FA

Voyons maintenant l'exigence RTS appelée liaison dynamique des transactions. Les transactions électroniques à distance (par exemple effectuées sur Internet, qu'il s'agisse d'un ordinateur de bureau ou d'un appareil mobile) devraient inclure des éléments qui «relient dynamiquement la transaction au montant spécifique (du paiement) et bénéficiaire. "

Cette exigence de SCA indique que le montant du paiement de la transaction avec qui le paiement est effectué doit être restitué à l'utilisateur au moment de la transaction 2FA.

Par exemple, un SMS reçu par l'utilisateur serait de vérifier le montant de l'achat et le commerçant, avec le code de sécurité (authentification) et les informations d'expiration pour ce code. Une chose à noter est que le montant de l'achat et le marchand ne sont pas cryptés.

Une alternative serait d'inclure une URL avec le code de sécurité dans le message SMS. L'URL serait liée aux informations de transaction liées et cryptées – accessibles via quelque chose que l'utilisateur sait, ainsi que le code de sécurité (reçu sur quelque chose que l'utilisateur possède).

Codes d'authentification générés par des applications TOTP tierces telles que Google Authenticator et bien d'autres sont complètement séparés des informations de paiement / marchand. La possibilité de relier dynamiquement ces codes à la transaction est quelque peu gênante.

En outre, la plupart de ces applications gratuites peuvent ne pas contenir les mesures appropriées pour prendre en charge la liaison dynamique des données de transaction et garantir que ces applications contiennent des contre-mesures. ainsi que le jailbreak et la détection des racines. Cela dit, certains SDK et API spécialisés peuvent fournir ces contre-mesures aux applications mobiles compatibles.

Cela signifie qu'un code d'authentification généré par une application TOTP tierce telle que Google Authenticator est généré séparément du paiement / L'exigence d'indépendance de la chaîne stipule que «les fournisseurs de services de paiement doivent adopter des mesures de sécurité lorsque l'un des éléments de l'authentification forte du client ou du code d'authentification lui-même est utilisé au moyen d'un dispositif multifonctionnel. »

Le périphérique multifonction peut être un périphérique mobile, une tablette ou un ordinateur portable. En fait, il y aura probablement des scénarios dans lesquels l'application bancaire / de paiement et l'application d'authentification sont sur le même appareil. Dans quelques cas, ils pourraient faire partie de la même application. Alternativement, l'application de paiement pourrait s'appuyer sur un canal d'authentification hors bande (comme le SMS).

Les canaux désignent les moyens d'interaction avec l'utilisateur. Le canal pour le paiement en ligne de l'utilisateur (ou l'accès au compte de paiement) et le canal utilisé pour l'authentification ne doivent pas être identiques. En ce qui concerne les combinaisons d'appareils disponibles sur le marché aujourd'hui, l'indépendance des canaux soulève un certain nombre de problèmes. L'authentification hors bande par SMS est largement déployée, facile à utiliser et très populaire auprès des consommateurs; En dehors des solutions hors bande telles que SMS, une autre bonne solution indépendante et pratique serait d'utiliser une messagerie push via une solution distincte d'authentification cloud vers une application d'authentification mobile. même l'application bancaire / paiement / marchand avec les informations de paiement ainsi qu'un code unique.

Une application d'authentification séparée qui incorpore les contre-mesures appropriées, recevant des informations liées dynamiquement via un canal crypté et indépendant est une autre méthode possible pour satisfaire ces exigences

Dans la troisième partie de cette série en trois parties, nous décrirons quelques options de mise en œuvre SCA qui devraient satisfaire aux exigences décrites dans le RTS, ainsi que quelques endroits où trouver plus d'informations.

Considérez s'il vous plaît qui me suit sur Twitter: @ wdudley2009

Cet article est paru à l'origine sur l'avenir de l'engagement des ommerce.

<! – Commentaires ->