Des chercheurs ont fait « revivre » des cartes VISA sans contact après expiration
Oups
Grâce à des failles dans le protocole de paiement sans contact et à son implémentation par VISA, il est possible d’effectuer des paiements sans contact alors que les cartes ont expiré.
Des cartes de crédits « zombies », c’est ainsi que des chercheurs de l’Université du Massachusetts Amherst qualifient certaines cartes de crédits VISA qui permettent de payer en mode sans contact alors qu’elles sont périmées.
Lorsqu’une carte de crédit arrive à péremption et qu’elle est remplacée par une nouvelle, on peut avoir tendance à se dire qu’elle est définitivement inutilisable par quiconque et s’en défaire sans trop de soucis. Mais ce n’est pas forcément le cas.
Raja Hasnain Anwar, Gerard DeCunha et Muhammad Taqi Raza ont expliqué comment ils ont réussi à passer outre cette date de péremption sur certaines cartes à la conférence Usenix qui s’est tenue à Baltimore la semaine dernière. Leur article, relu par des pairs, est en ligne sur le site de Usenix.
Ils y expliquent que les cartes qu’ils ont pu faire « revivre » ont bien toutes des dates de péremption mais que le protocole sans contact EMV créé par Europay, Mastercard et Visa (d’où son nom) et surtout son implémentation par VISA permettent de passer outre.
L’implémentation de VISA laisse particulièrement à désirer
Commentaires (33)
Modifié le 19 août à 15h31
Juste un bemol, pour les vieux (comme moi ) qui ai connu l'époque de "fer à repasser", et des copies carbonnes on nous avait appris à recuper le carbonne et lors de l'expiration de la carte de la détruire (triples coups ciseaux voir brulage de la carte).
Le 19 août à 15h58
Ou alors tu découpe ton téléphone si le process de suppression du wallet est trop chiant (ce qui arrive parfois)
Le 19 août à 18h57
Le 19 août à 15h36
Le 19 août à 15h44
Ou alors est-ce que c'est visa qui perds en ne pouvant pas valider la transaction auprès de la banque ?
Dans ce dernier cas c'est peut-être un risque maîtrisé et tant que ça ne leur coûte pas trop cher ils laissent faire ?
Ce passage de l'article va dans ce sens :
Le 19 août à 15h56
L'argent est bien pris quelque part.
Je suis curieux de la réponse de Visa France à Next, si vous pouvez mettre à jour l'article en suivant.
Le 19 août à 16h04
Le 19 août à 16h23
Le 19 août à 17h42
Modifié le 19 août à 19h01
Et à chaque projet où tu réimplémentes des patterns standards, t'as l'impression qu'il faut encore tout réexpliquer et qu'ils vont redévelopper la roue encore et encore. Et ce en travaillant avec la même personne. Pire qu'un LLM dont on efface le contexte.
Une perte de thunes.
Pour donner un exemple dans mon domaine : ils n'ont jamais compris que coder en dur des codes magasins n'était pas la meilleure approche pour un déploiement.
Le 22 août à 15h38
Le 22 août à 17h28
Rien que tout à l'heure Waze sur Android. La playlist de musique que j'avais s'arrêtait, soudainement les instructions vocales se tronquent.
Bref, des boîtes qui brassent des milliards et font des produits à peine fonctionnels pour du basique.
Le 22 août à 17h34
Le 22 août à 17h36
La réalité que je constate dans tous les cas : une énorme perte de temps et d'argent.
Le 20 août à 09h35
Le 20 août à 06h49
C'est la combinaison d'une mauvaise implémentation de Visa pensée pour les paiements hors ligne (genre métro) et de ce que tu décris : ils peuvent jouer sur la devise ou un truc du genre pour contourner la limite absolue (je ne me souviens plus exactement).
Le 19 août à 23h02
Ça me donne l'impression d'un dev mal foutu où les vérifications sont faites uniquement en front et que le back laisse tout passer parce que le token est bon...
Le 20 août à 07h39
Le 20 août à 10h33
Les serveurs peuvent être dimensionnés en conséquence.
Modifié le 20 août à 08h30
Sans parler de la latence derrière. Faut pas croire que tous les commerces sont sur des fibres en GB
Le 20 août à 10h38
Et puis ça veut dire que si le réseau d'un magasin tombe et qu'une transaction ne devrait pas passer car serait rétorquée par le serveur (exemple, carte bloquée), alors elle passe quand même.
Autant je comprends tes arguments, autant ça me semble une prise de risque non négligeable.
Le 20 août à 10h42
Lorsque l'établissement bancaire reçoit ces lots de paiements, elle fait ensuite un rapprochement avec les mouvements sur les comptes bancaire - la phase de "réconciliation". Il peut y avoir des ratés qui sont alors en général à la charge de la banque s'il n'y a pas suspicion de fraude.
C'est pourquoi pas mal de banques ont bien accueilli Apple Pay. La phase d'identification biométrique est une vérification supplémentaire qui diminue les risques d'erreur ou fraude. L'économie faite par ce risque en moins compensait la commission prélevée par Apple.
Le 20 août à 11h15
La fréquence pour le soir est variable puisque les appels sont généralement payant à la charge du commerçant.
La "réconciliation" elle n'est pas forcément faite là où tu penses et pour les raisons que tu penses (dans le cas où la partie temps réelle à fait un appel). Le fonctionnement sans "réconciliation" comme tu l'appelles marche très bien en France même si ça a certains incovénients parfois.
En cas de fonctionnement "OFFLINE", que la banque autorise sous condition au commerçant, c'est le commerçant qui prend le risque s'il accepte une transaction, pas la banque.
L'accueil d'ApplePay pour les banque ? j'ai pas la même vision que toi... En France, les banques ne l'ont pas fait de gaité de cœur pour 2 raisons, dont la dime Apple côté émetteur de cartes. JE vous laisse regarder la vaste littérature disponible à ce sujet en ligne :)
Côté US c'est autre chose, ils sont passez de la piste avec signature à ApplePay, donc bien plus sécurisé, en France, on est passé d'un code PIN personnel à .... ApplePay, le gain de temps est marginal côté France/Europe, mais bien plus important côté US.
Le 21 août à 08h17
Le 20 août à 21h06
Pour les cartes d'étudiant -type visa electron- ou (les cartes tickets restau...) la carte refuse tout systématiquement, et le TPE déclenche un appel systématique à la banque: c'est très chiant surtout si le TPE n'a pas le réseau (il faut le remettre sur la base le temps de la transaction, et ça mouline 15/20 sec : pas très pratique pour régler sur une terrasse par exemple)
Donc non le dev est plutôt bien foutu, et c'est la puce de la carte qui porte la sécurité, le TPE ne fait qu'agir sur instruction (demander le code, demander le contrôle à la banque...)
Modifié le 21 août à 09h06
Il s'agit cependant d'un cas nominal. On pourrait se poser la question des arbitrages en cas de mode dégradé : des problèmes de communication réseau du TPE doivent-ils l'amener à refuser les paiements, ou les accepter, quitte à ne pas les vérifier ou le faire plus tard ?
En fonction de notre profil (client, commerçant, intermédiaire de paiement, banquier ou technique), nous aurons certainement des priorités différentes…
Je me souviens pour ma part avoir réussi à trouver & inhiber physiquement l'antenne NFC sur mon ancienne carte bancaire; je n'ai pas retenté la manipulation sur la nouvelle.
Le 20 août à 08h33
Le 20 août à 10h04
Le système est prévu pour être resillent, une partie des contrôles sont fait en local, et une autre partie sont prévus "Online". Je ne préciserai pas ce qui est fait "Online" puisque ce sont les toutouilles de chaque banque et que la doc "générale" n'est pas en diffusion libre.
Le mode dégradé est prévus parce qu'un système n'est jamais up à 100% quoi que tu fasses.
@SoriataneLes systèmes sont prévus pour du 100% appels dans la mesure où le mode "connecté" est la règle pour de nombreux réseaux d'acceptation, et en raison d'évolutions technologiques également.
Pour fonctionnement réelle derrière, il y a plein de paramètres qui sont vérifiés, tant en local qu'à distance du côté des banques.
@SebGFLes TPE dans les Hyper/Super sont en connectés filaire, plus fiable, non soumis à la réception d'un signal dans une cage de Faraday, ...
Cela n'empêche pas les coupures au niveau du magasin, de la banque, du réseau d'acceptation (CB/Visa/Mastercard/Amex/Discover/...),
La plupart des cartes à autorisation systématiques (et y'en a bien plus que tu ne peux l'imaginer en réalité) on généralement un plafond "OFFLINE" pour fonctionner, le montant est variable suivant les banques.
Pour les cartes "rechargeables" par contre ce n'est pas le cas, donc la carte est bloquée.
Concernant la latence, elle est plutôt bonne puisqu'il n'est pas nécessaire d'avoir la fibre pour faire passer des dizaines d'appels en parallèles
Le 20 août à 21h11
Modifié le 21 août à 09h13
Ou alors une zone d'ombre a été tranchée dans l'urgence car il fallait livrer "hier".
Ou alors des arbitrages ont été faits pour laisser passer les choses en état dégradés.
Ou alors des options sont possibles sur les TPE ou au niveau de l'intermédiaire de paiement et les commerçants ne sont pas au courant de la valeur par défaut.
Conjectures, conjectures, conjectures…
Ce réflexe de considérer que les développeurs (autres que soi) sont des branquignoles, et que tout problème fonctionnel soit immédiatement attribué au développement…
Le 21 août à 10h08
Après, là, on parle d'un équivalent à un enregistrement en base de données : en tant que développeur, tu DOIS TOUJOURS vérifier l'intégrité de tes données côté serveur avant de les stocker (sauf si, bien sûr, il n'y a aucun contrôle à faire, mais c'est excessivement rare). Sinon, un petit malin peut insérer des données corrompues dans ton système, ce qui peut aller jusqu'au piratage du serveur (coucou les SQL injections). C'est pour ça que je parle de "dev mal foutu".
Modifié le 21 août à 11h22
Oui, il y a les pratiques du développement sécurisées à mettre en oeuvre, dans la théorie.
Dans la pratique, quand t'as un projet qui se pointe en mode urgent, sans specs, à livrer pour hier et avec 3 pesos de budget, ben tu fais avec la pression qu'on t'inflige. C'est ensuite de la gouvernance avec une chaîne de responsabilité.
Le 21 août à 11h44
L'idée n'est pas de dire que si un dev est mal fait, c'est forcément de la faute du développeur. Il y a les faits d'un côté et les causes de l'autre. Pas besoin de rajouter du jugement en plus. 😉
Signaler un commentaire
Voulez-vous vraiment signaler ce commentaire ?