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.
- 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.
- 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 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.
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).
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.
<?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.
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.
Commentaires
Enregistrer un commentaire