Est-ce que quelqu'un connaît une implémentation d'une formule Luhn améliorée ou augmentée pour vérifier les chiffres de contrôle "double-addition-double" de module-10 sur les cartes de paiement?Implémentation de l'algorithme amélioré de Luhn?
amélioration a été suggéré dans cet article: http://d.researchbib.com/f/6nnJcwp21wYzAioF9xo2AmY3OupTIlpl9XqJk5ZwNkZl9JZxx3ZwNkZmpmYaOxMt.pdf
Est-ce qu'un Luhn amélioré chèque soit l'utilisation pratique?
Il est un peu étrange que ce document a été accepté dans une revue par les pairs. L'article décrit ce qui a essentiellement été identifié comme étant un problème avec la somme de contrôle de Fletcher dans les années 1970; La longueur et la transposition des données ne peuvent pas être détectées avec précision.
Mais nous allons réfléchir sur les aspects pratiques de cette proposition. Si vous creusez vraiment dans les détails, il est vraiment impossible à mettre en œuvre pour de nombreuses raisons.
L'algorithme Luhn a été fait comme une méthode simple, meilleur effort pour valider un numéro de carte. À l'époque où les cartes de crédit commençaient à être largement traitées électroniquement (elles avaient déjà été imprimées sur papier), il n'y avait pas de réseau permanent pour appeler un service à valider. Le Luhn peut être implémenté sans besoin de connectivité réseau pour effectuer la validation. C'est la première prémisse pour établir l'infaisabilité: vous devez être en mesure d'effectuer la validation sans avoir besoin de traverser le réseau.
Cette prémisse « non traversal réseau » fait la recherche PPFI infaisable. Il existe deux façons de mettre en œuvre ceci:
Traitement de l'autorisation de la carte peut être asynchrone. Amazon fait cela; ils confirment la réception de votre commande et vous confirmeront souvent le traitement du paiement plus tard.
Enfin, l'auteur a fait une fausse hypothèse sur la longueur de la carte. L'algorithme de Luhn fonctionne bien pour de nombreuses longueurs car la longueur du numéro de carte peut être plus longue ou plus courte que 16 chiffres. Les cartes grand public ont 15 chiffres pour Amex et 16 pour les autres cartes. Les cartes commerciales peuvent comporter plus de 16 chiffres; J'ai vu des cartes d'essence commerciales jusqu'à 20 chiffres. Si l'auteur avait examiné la norme CEI/ISO 7812, cela aurait été compris. Le comité de normalisation propose même d'étendre la longueur du numéro de carte standard. La grande chose est que quand/si la longueur du numéro de carte est étendue, l'algorithme de Luhn valide toujours la carte. Faites-vous plaisir, comptez sur le Luhn comme première étape, mais laissez le processeur faire le gros du travail en validant que la carte est indéniablement correcte via le réseau de traitement de cartes existant.
J'ai fait une recherche sur Google et trouvé une implémentation dans le logiciel des deux mêmes améliorations proposées par Hussein et al, dans une vérification de Luhn par un développeur de logiciels, Pawel Decowski. C'est son validateur de carte de crédit jQuery, (Decowski, 2015/2016). Je voudrais spéculer que Decowski a été influencé par Hussein et al.
Decowski, P. (2015/2016) jquery-creditcardvalidator [En ligne]. Disponible au https://github.com/PawelDecowski/jquery-creditcardvalidator (Consulté le 11 avril 2017).
Non, pas vraiment. La seule façon de valider un PAN au-delà du trivial est de l'envoyer à l'acquéreur pour tenter une autorisation - de la même manière que la seule façon de valider un numéro de téléphone est de l'appeler. Je ne vois pas le point de ce document ou toute proposition valide contenue dans ce document, l'hypothèse de la longueur d'un pan est un 16 chiffres fixes est tout simplement faux pour un début. –