Paiements à distance : pour une authentification renforcée et plus facile du commerçant

Schéma simplifié d’un paiement ‘à distance’ :

PSP : Prestataire de Service de Paiement (ou Payment Service Provider)

1 - un client décide d’acheter sur un site en ligne ou contacte un centre d’appel (catalogue, émission TV, …)
2 - le commerçant transmet les informations nécessaires (numéro de carte, …) à l’organisme chargé d’assurer le paiement effectif, généralement un PSP.
3 - ce dernier procède à des vérifications auprès des établissements financiers concernés (demande d’autorisation, …) et retourne la réponse au commerçant qui valide ou non la commande.

En matière de protection des informations de paiement sur InterNet, on se focalise souvent sur la première partie du trajet : celle entre l’acheteur et le commerçant. On essaye alors de sensibiliser les clients aux « bonnes pratiques » lors d’un achat à distance.

A l’autre bout de la chaine on peut espérer une sécurité suffisante si les recommandations PCI-DSS sont strictement respectées.

Mais quelle est la situation entre le commerçant et son « fournisseur de paiement » ?

Outre la sécurité du site commerçant lui-même, se pose le problème de l’authentification mutuelle des 2 parties. Bien que le commerçant puisse authentifier le PSP grâce à son certificat, la réciproque est délicate et malaisée (le certificat du commerçant est délivré pour être utilisé sur un réseau public, pas sur le réseau privé du PSP). Or, lors du paiement, le commerçant doit s’assurer qu’il transmet bien les données à son PSP, mais le PSP, lui, doit aussi s’assurer que c’est bien son commerçant qui lui parle.

C’est déjà bien compliqué jusque là, mais en plus il faut prendre en compte le chemin inverse : le PSP doit pouvoir s’authentifier auprès du commerçant quand il lui envoie des notifications décalées dans le temps (IPN : Instant Payment Notification, notification instantanée de paiement).

Pour répondre à ces problématiques, les PSP ont imaginé il y a quelques années déjà des solutions qui semblent aujourd’hui bien « artisanales » et qui soulèvent d’autres problèmes.

Techniquement ces solutions reposent généralement sur le calcul d’un condensé (HMAC) au moyen d’une clé symétrique ou un mot de passe, ou la vérification d’une signature utilisant une clé [pseudo-]privée. Il en résulte un protocole de sécurité applicatif propriétaire bricolé par-dessus un canal de communication TLS. C'est peu satisfaisant sur le plan conceptuel et la réalisation n'est pas triviale.

Pour les commerces qui s’appuient sur les moteurs de boutiques en ligne les plus répandus, il existe des composants logiciels prêts à l’emploi. Ils prennent en charge l’utilisation de la clé, mais se soucient peu de sa protection, et avec les langages de script utilisés, c’est à chaque paiement qu’il faut relire la clé secrète ou le mot de passe !

Pour les autres, il faudra [faire] développer l’interface spécifique au PSP. Ceux-ci fournissent des exemples de code et des kits de développement, mais rien ne garanti un résultat fiable et sécurisé. De beaux débats en perspective pour déterminer les responsabilités en cas de litige ou de fraude …
De plus ce travail n’est pas « portable » : le commerçant ne peut changer de PSP sans recommencer un développement et bouleverser à nouveau ses processus de vente et son informatique interne, ce qui est à la fois couteux et risqué.

Va-t-on continuer longtemps dans cette voie ?

Aujourd’hui les moyens existent pour construire des solutions qui soient plus robustes, fiables et performantes.
Des solutions qui soient basées sur des protocoles cryptographiques standards plus modernes, offrant une meilleure sécurité.
Des solutions qui soient évolutives, que l’on puisse auditer et qui ne mélangent pas sécurité et messages applicatifs.
Des solutions qui peuvent être installées et supervisées par un administrateur.

Concerné, intéressé ?
N'hésitez pas à me contacter : ISO8583free.fr