3DSecure 1.0: Pourquoi le 3 et pourquoi le D?

Le 14 juin 2017, le support PayZen a été mis à rude épreuve par une panne gigantesque et inacceptable dans la chaîne d'authentification des porteurs.

Pour l'expliquer proprement, il est important de rappeler comment le 3Dsecure fonctionne.

Que signifie 3D?

• le chiffre 3 est en rapport avec le système d'authentification à 3 acteurs. 

• la lettre D car ces acteurs correspondent à un domaine. 

Quels sont ces domaines?

• le DS abréviation de Directory Server qui est contrôlé par la marque : Visa, Mastercard, AMEX, JCB, etc..

• l'ACS qui est le serveur d'authentification de l'émetteur de la carte

• le MPI (merchant plug-in interface) qui est géré par la plateforme de paiement ou par le marchand lui-même s'il a décidé d'avoir une intégration propriétaire et agréée. 

Comment cela fonctionne?

• un id

• la référence du marchand, 

• le numéro de la carte. 

• le bin acquéreur

• le user agent

• la version de 3DS

• le mot de passe d'accès au DS

• la version de 3DS

Que fait le DS avec cette requête?
Que s'est il passé le 14 Juin?
Conséquences:

• je veux une autorisation de x euros pour ce marchand enrôlé 3DS et pour cette carte non enrôlée.

En résumé:
Un système complexe basé sur 3 domaines mais si un seul estdéfaillant, tout tombe comme un château de carte...

Tous les 3 dialoguent entre eux pour authentifier un porteur.

Tout commence par la saisie de la carte du porteur en général via une plateforme de paiement. (PayZen en ce qui nous concerne).

Une fois la carte saisie, PayZen vérifie que le commerçant a adhéré à 3DS. « Adhérer à 3DS » cela signifie être enrôlé dans le référentiel du DS.  

De plus, le Mpi doit avoir l'autorisation d'interroger le DS pour tous les bins acquéreurs de ses marchands. C'est une procédure parfois lourde qui demande parfois des mois de patience avant que les formalités (une page!!) soient signées. Cela fait un an que j'essaye de faire signer Visa Perou. Mais l'encre est rare au Pérou. Et on a  mis 6 ans pour signer HSBC France. Nous n'étions selon eux pas agréés. Quand on veut protéger son prestataire, on dit que le voisin a la rage.

Pour appeler le DS, le MPI envoie une requête qui s'appelle un  VEreq. Cette requête contient peu d'éléments:  

<?xml version="1.0" encoding="UTF-8" standalone="yes"?><ThreeDSecure><Message id="_5txyxthiykdxxxxxxA3dnpy"><VEReq><version>1.0.2</version><pan>4758xxxXXXXXX1045</pan><Merchant><acqBIN>4xxx00</acqBIN><merID>3zzzzz50</merID><password>xxxxxx</password></Merchant><Browser><userAgent>Mozilla/5.0 (Windows NT 5.1; rv:36.0) Gecko/20100101 Firefox/36.0</userAgent></Browser></VEReq></Message></ThreeDSecure>

Le DS possède une table des bins (6 premiers chiffres de la carte) qui lui donne l'adresse de l'ACS capable de traiter la requête. Cette table contient l'adresse de l'ACS primaire et l'adresse secondaire. Sauf quand le deux sont identiques, il n’y a donc pas de backup. 

Le DS va donc envoyer, à partir des données du VeReq une requête à l'ACS pour lui demander si la carte est enrôlée.

Si la carte est enrôlée, en réponse de l'ACS, le DS répondra au MPI un VEres avec l'adresse du serveur d'authentification.

Contrairement à ce qu'écrit Pierre Col dans cet article, ce n'est pas une défaillance dans les requêtes d'autorisation  qui a créé le problème mais bien une défaillance dans les requêtes d'authentification.

http://www.zdnet.fr/blogs/infra-net/panne-du-systeme-de-paiement-3d-secure-a-cause-du-nom-de-domaine-39853696.htm

Lorsque la carte est enrôlée, le DS renvoie ce type de message dont 2 champs vitaux : "url et "enrolled"

<?xml version="1.0" encoding="UTF-8" standalone="yes"?><ThreeDSecure><Message id="_pFln8xvpXXXXXX"><VERes><version>1.0.2</version><CH><enrolled>Y</enrolled><acctID>AAUgFwQGEXXXXXXXXXX=</acctID></CH><url>https://aacsw.3ds.verifiedbyvisa.com/aacs/pahandler?vgtli=000520170406110328423XXXXXXXXX0;vgp=eNo1jtXXXXXXXXXXXX</url><protocol>ThreeDSecure</protocol></VERes></Message></ThreeDSecure>

Quand tout se passe bien, le champ enrolled est égal à Y et le champ url contient l'adresse de l'ACS.

Dans ce cas la plateforme de paiement  via son MPI propose au navigateur de l'acheteur une redirection vers le serveur d'authentification de l'émetteur de sa carte. On appelle cela un PAreq. 

Le porteur une fois redirigé, doit s'authentifier. La plateforme de paiement attend la réponse. Elle perd le contrôle total de l'authentification car c'est un tiers de confiance qui traite l'authentification. 

Ssuite à la suppression du nom de domaine de tous les FAIs de la terre pour non renouvellement du nom de domaine qu'ATOS utilise pour ses ACS, le DS de VISA a renvoyé pour toutes les CB françaises (hors CIC / CME qui ne travaille pas avec ATOS) le champ enrolled à N.

Hors ce n'est pas possible. Toutes les cartes CB sont enrôlées.

Le protocole d'autorisation impose d'envoyer les champs correspondant au contexte 3DS de la transaction.

On a donc fait dans le pur respect du protocole, une demande d'autorisation en disant à l'émetteur:

Hors l'émetteur sait que cette carte est enrôlée. Donc il est impossible qu'on lui demande une autorisation pour une carte non enrôlée qui est obligatoirement enrôlée. 

Du coup refus en code 05  pour toutes les autorisations de porteurs de banques françaises hors CIC et CME. 

Ce n'est pas la première fois que la communication entre le DS et l'ACS de ce tiers de confiance est rompue (cas grave avant Noël en 2015 de mémoire pendant plus de 2 heures) mais c'est la première fois que cela dure aussi longtemps.

Vu de notre fenêtre, plus 60% des paiements ont été refusés. 

Les commerçants qui ont désactivé 3DS ont pris le risque de prendre de la fraude.

Tous les sites de paris en ligne où 3DS est obligatoire ont été fortement impactés.