DSP2 : authentification forte du client dans l'UE

Il s'agit du deuxième d'une série d'articles en trois parties détaillant PSD2 : Authentification forte du client dans l'UE (SCA).

Dans le premier volet de cette série en trois parties, nous avons présenté la directive de l'Autorité bancaire européenne (ou EBA) de l'Union européenne appelée PSD2 (abréviation de la deuxième directive sur les services de paiement) et décrit certains des principes directeurs de l'authentification forte du client (ou SCA) .

Se référant à la 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). Comme indiqué dans la partie 1, 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.

Dans cet article, nous explorerons les limites de la SCA et les régulateurs que les implémenteurs doivent prendre en compte. Examinons d'abord les codes d'authentification qui sont générés. N'oubliez pas 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érivée de la divulgation du code d'authentification. Cela signifie que si vous connaissez le code d'authentification, il n'y a aucun moyen de dériver tout autre élément de connaissance (par exemple un identifiant d'utilisateur), ce que l'utilisateur a en sa possession (disons un téléphone portable - ce qui signifie que vous ne pouvez pas dériver le numéro de téléphone portable) 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 à partir de la connaissance d'un autre code d'authentification précédemment généré . Pour cette condition, étant donné n'importe quel code d'authentification, il n'y a aucun moyen de générer un nouveau code d'authentification en référençant 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 afin que les codes falsifiés ou faux ne puissent pas être validés avec succès.
• Pas plus de 5 tentatives d'authentification infructueuses ne doivent être tentées pendant la durée de vie du code. Chaque code généré aura un délai d'expiration ou "durée de vie". Cette minuterie démarre immédiatement après la génération du code et inclut le délai de livraison. Une bonne règle de base est que le code doit expirer dans 15 minutes ou moins. Certaines organisations prennent cela à 30 minutes ou 1 heure, mais cela peut être trop long. Si l'utilisateur tente de s'authentifier avec le code et échoue 5 fois, un nouveau code doit être envoyé. Cela empêche tout type de tentative de force brute pour comprendre le code.
• 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 peut excéder 5 minutes . Il s'agit d'un temporisateur d'inactivité standard et bien que distinct du code d'authentification, il s'agit d'un temporisateur qui démarre une fois que l'utilisateur est authentifié avec succès et n'effectue aucune activité.

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

Examinons maintenant l'exigence RTS appelée Dynamic Linking of the Transactions. Les transactions électroniques à distance (par exemple, effectuées sur Internet, que l'appareil soit un ordinateur de bureau ou un appareil mobile) doivent inclure des éléments qui « relient dynamiquement la transaction au montant spécifique (du paiement) et au bénéficiaire spécifique.

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

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

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

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

De plus, 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 pour garantir que ces applications contiennent des contre-mesures pour perturber le clonage des applications 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 conformes.

Cela signifie qu'un code d'authentification généré par une application tierce compatible TOTP telle que Google Authenticator est généré séparément des informations de paiement/marchand et ne peut donc pas être lié dynamiquement.

L'exigence d'indépendance du canal 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 cette multi-fonctionnalité". l'appareil à usage spécifique est compromis. »

L'appareil polyvalent peut être un appareil 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 se trouvent sur le même appareil. Dans quelques cas, ils pourraient faire partie de la même application. Alternativement, l'application de paiement peut s'appuyer sur un canal d'authentification hors bande (comme les SMS).

Les canaux font référence aux moyens d'interagir avec l'utilisateur. Le canal de paiement en ligne (ou d'accès au compte de paiement) de l'utilisateur 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 via SMS est largement déployée, facile à utiliser et très populaire parmi les consommateurs ; cependant, il a des problèmes de sécurité perçus.

Outre les solutions hors bande telles que les SMS, une autre bonne solution indépendante et viable du canal consisterait à utiliser une messagerie push via une solution d'authentification cloud distincte vers une application d'authentification mobile ou même l'application bancaire/paiement/marchand avec les informations de paiement comme ainsi qu'un code unique.

Une application d'authentification distincte qui intègre 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 répondre à ces exigences.

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

Merci de me suivre sur Twitter : @wdudley2009

Découvrez les effets que la crise sanitaire actuelle pourrait avoir sur la stratégie commerciale, la transformation numérique et l'avenir du commerce électronique ICI.