Comment un site Web sait-il instantanément si un certain numéro de carte de crédit est erroné

Peteris

2015-02-16 23:11:50 UTC

view on stackexchange narkive permalink

Sommes de contrôle

Les numéros CC, ainsi que presque tous les autres numéros importants bien conçus (par exemple, les numéros de compte dans les banques) ont tendance à inclure une somme de contrôle pour vérifier l'intégrité du numéro. Bien qu'il ne s'agisse pas d'une fonction de sécurité (car il est facile à calculer), un algorithme de somme de contrôle décent peut garantir de toujours échouer si (a) une seule faute de frappe a été faite ou (b) deux chiffres voisins sont échangés, qui sont les deux erreurs les plus courantes lorsque manuellement entrer des nombres longs.

http://rosettacode.org/wiki/Luhn_test_of_credit_card_numbers est un exemple d'un tel test.

Émetteur

Si un numéro CC est techniquement correct, il se peut qu’il ne s’agisse toujours pas d’un véritable numéro CC. La méthode de vérification qui est à la fois simple et compliquée - généralement, si vous disposez d’un accès approprié, vous pouvez rechercher l’institution émettrice pour chaque plage de numéros de carte, puis vous demandez à l’émetteur [les systèmes de cartes] si ils pensent que c'est une carte valide. Eh bien, la deuxième partie se déroule généralement dans le cadre d'un paiement CC, mais la vérification de l'émetteur est parfois effectuée avant cela comme un test prolongé; mais pas sur le navigateur client.

À titre d'exemple de "techniquement correct", le numéro de carte Visa-ish 4111-1111-1111-1111 passe le test de Luhn, mais n'est clairement pas réel.

@Bobson Je suis presque sûr que c'est un numéro de test.

@MiniRagnarok - Oui. C'est le test standard pour Visa spécifiquement parce qu'il * réussit * Luhn.

En règle générale, si le FAI a l'intention de débiter réellement la carte de crédit, il autorisera un petit montant sur celle-ci (par exemple 1 USD). Cela ne réduira pas le solde, mais servira d'indicateur rapide, prenant environ le temps d'une demande Web, si la carte est réellement valide, étant donné que la banque de la carte doit confirmer le montant autorisé. Ceci est souvent fait après avoir vérifié la validité syntaxique de la carte pour réduire considérablement les risques de rebond des cartes de crédit.

EarlCrapstone

2015-02-16 21:40:00 UTC

view on stackexchange narkive permalink

Aux États-Unis, ils utilisent l'algorithme de Luhn:

http://en.wikipedia.org/wiki/Luhn_algorithm

Comment le l'algorithme vérifie un nombre:

À partir du chiffre le plus à droite, qui est le chiffre de contrôle, en se déplaçant vers la gauche, double la valeur de chaque deuxième chiffre; si le produit de cette opération de doublement est supérieur à 9 (par exemple, 8 × 2 = 16), alors additionnez les chiffres des produits (par exemple, 16: 1 + 6 = 7, 18: 1 + 8 = 9).
Prenez la somme de tous les chiffres.
Si le total modulo 10 est égal à 0 (si le total se termine par zéro) alors le nombre est valide selon la formule de Luhn; sinon il n'est pas valide.

Comment calculer le chiffre de contrôle:

Le chiffre de contrôle est obtenu en calculant la somme des chiffres puis en calculant 9 fois cette valeur modulo 10 . Sous forme d'algorithme:

Calcule la somme des chiffres (après avoir doublé tous les deux chiffres).
Multiplier par 9.
Le dernier chiffre est le chiffre de contrôle.

Exemple:

Numéro: 4321-5678-7531-456x (où x est le chiffre de contrôle).

  1. Numéro: 4 3 2 1 5 6 7 8 7 5 3 1 4 5 6 X2. Double chaque seconde: 8 4 10 14 14 6 8 123. Somme des chiffres >9: 8 3 4 1 1 6 5 8 5 5 6 1 8 5 34. Somme de tous les chiffres: 8 + 3 + 4 + 1 + 1 + 6 + 5 + 8 + 5 + 5 + 6 + 1 + 8 + 5 + 3 = 695. Multipliez la somme par 9: 69 x 9 = 6216. Prenez la valeur mod 10: 621 mod 10 = 1 = > x = 1

Le chiffre de contrôle est 1 et le numéro valide complet est 4321-5678-7531-4561.

Si vous deviez réexécutez l'algorithme pour vérifier le nombre, puis la somme de tous les chiffres de l'étape 4 serait 69 + 1 = 70 . Ensuite, 70 mod 10 = 0 , donc le nombre est valide selon l'algorithme.

Je l'ai essayé sur mon numéro et apparemment, il utilise un algorithme différent.

@tony9099 En fait, en utilisant MOD 10, ils manquaient de nombres valides, donc ils (les banques) sont passés à un algorithme modifié qui utilise MOD 5 à la place, mais le principe est le même. Le chiffre de contrôle doit forcer la valeur totale de la somme (comme décrit) à se terminer par 5 ou 0. Toutes les cartes aux États-Unis utilisent cet algorithme, mais c'est au fournisseur de cartes de décider s'il utilisera MOD 10 ou MOD 5. Par exemple, je suis presque sûr que Diners utilise MOD 10, tandis que Visa et Mastercard utilisent MOD 5.

Comment peuvent-ils changer d'algorithme de vérification avec des millions de terminaux de cartes de crédit et d'applications logicielles sur le terrain qui devraient être réécrits avec le nouvel algorithme?

Les terminaux et applications logicielles @Johnny peuvent simplement utiliser la version mod 5. Tout nombre qui réussit le test du mod 10 passera par définition également le test du mod 5.

@Johnny Ce changement s'est produit il y a plusieurs décennies, à l'époque où les terminaux étaient plus stupides et transmettaient à l'aveuglette tout ce qui passait la somme de contrôle magnétique en glissant la carte. La saisie manuelle était également possible, mais ces systèmes n'ont pas effectué de validation, mais ont plutôt gaspillé de la bande passante en téléphonant à la maison (à une banque, etc.) avec le numéro invalide. En fait, je suis à peu près sûr que la plupart des terminaux d'aujourd'hui ne supposent pas qu'un numéro valide est celui qu'ils peuvent vérifier hors ligne. Quelques sites Web utilisent la validation de base (par exemple, un 4 de départ est Visa et 16 chiffres), mais peu mettent en œuvre la vérification Luhn.

Luhn est largement utilisé, pas seulement aux États-Unis. Cependant, ce n'est pas la seule vérification immédiate qui peut être effectuée sans se connecter à l'hôte d'autorisation de l'émetteur de la carte.

baordog

2015-02-16 21:39:03 UTC

view on stackexchange narkive permalink

De nombreux sites ont des contrôles côté client sur le CC #. Tous les numéros de carte de crédit ont à peu près la même longueur. (Comme le soulignent les commentateurs, il existe plusieurs longueurs. En général, les longueurs sont connues de l'implémenteur et il y a un petit ensemble.) Il existe des chaînes de nombres qui se rapportent à chaque fournisseur.
Du point de vue de la sécurité, il vaut mieux également effectuer des vérifications côté serveur. Si vous êtes un testeur de stylo, ce serait quelque chose à vérifier. Si ce n'est pas le cas, évitez de le faire car vous pourriez avoir de gros problèmes.

https://www.mint.com/blog/trends/credit-card-code-01202011/

L'échange de piles consiste à rester sur le sujet. Cela ne concerne pas tous les sujets sur terre. Il est normal que les gens sachent que cela a été vrai à chaque échange de pile.

Le fait est que ce n'est pas Stack Exchange, c'est https://security.stackexchange.com/ donc ma question était liée à la sécurité. Donc, je pense que c'est valable. Je n'ai pas besoin que vous me disiez que ce n'est pas le cas.

C'est une question de sécurité très valable. Il y a longtemps, vous n'aviez pas besoin d'un ordinateur pour formuler des numéros CC valides. C'est pourquoi CCV est désormais implémenté.

"Tous les numéros de carte de crédit ont la même longueur." - Êtes-vous sûr?

*> [Un numéro de carte ISO / CEI 7812 est le plus souvent composé de 16 chiffres et peut comporter jusqu'à 19 chiffres.] (Http://en.wikipedia.org/wiki/Bank_card_number) *; AmEx est composé de 15 chiffres.

@Virusboy Votre commentaire "C'est pourquoi CCV est maintenant implémenté" - y a-t-il un moyen de pré-vérifier un CCV? Est-ce lié au CC # d'une manière ou d'une autre?

@tcrosley c'est quelque chose que je n'ai pas pu déterminer. Les facteurs impliqués sont l'émission du numéro de banque ou du RNG de l'émetteur de la carte de crédit.

MikeRoger

2015-02-17 18:51:45 UTC

view on stackexchange narkive permalink

Sommes de contrôle, reconnaissance de plage de cartes et vérifications de longueur

La plupart (mais pas tous) les systèmes de cartes utilisent le test de somme de contrôle (Luhn) décrit dans d'autres réponses. Cependant, en plus, certains algorithmes utilisent également (assez basique) la reconnaissance de plage de cartes (CRR) basée sur le début du numéro de carte (AKA la plage). Certains vérifient également la longueur de la carte.

Voir par exemple les similitudes dans de nombreux algorithmes décrits sur: - https://stackoverflow.com/questions/72768/how-do-you- détecter-le-type-de-carte-de-crédit-basé-sur-le-numéro

Certains collègues m'ont récemment mis sur http://www.exactbins.com/bin-lookup. Ils le trouvent plus fiable que les sites concurrents. Cependant, j'ai une mise en garde: pour moi, cela identifie mal les gammes que nous avons d'UPI, comme Maestro plutôt que UnionPay.

user68527

2015-02-22 18:46:07 UTC

view on stackexchange narkive permalink

Juste pour être complet: l'algorithme de Luhn a un défaut mineur.

TL; DR: "l'algorithme de Luhn détecte la transposition des chiffres adjacents s'ils ne sont pas 09 ou 90"

Si d1 et d2 sont des chiffres adjacents dans le numéro de carte de crédit (d1! = d2), alors leur contribution à la somme de contrôle est soit f (d1) + d2 ou f (d2) + d1, et s'ils sont transposés, ils sont soit f (d2) + d1, soit f (d1) + d2. Si ces deux sommes sont identiques ou si leur différence est un multiple de 10, alors la somme de contrôle ne fait pas la distinction entre leur transposition.

"Cartes de crédit" 2007, en An Introduction to the Mathematics of Money , Springer New York, NY, pp. 101-112.

La fonction f (d) est la doublement et somme des chiffres qui pourraient être définis comme suit en python pour les entiers d : def f (d): return sum ([int (x) for x in str (2 * d) ])

Il n'y a pas deux chiffres qui seront zéro mod 10 dans le scénario ci-dessus. La preuve est fastidieuse, mais elle peut être trouvée dans son intégralité dans la ressource suivante à partir de laquelle j'ai pris la citation de bloc ci-dessus.