Que signifient les chiffres d'une carte bancaire ?

Proposé par
le

Les 16 chiffres de votre carte bancaire ont une signification particulière. Les 6 premiers identifient l'organisme émetteur de la carte, et les 9 suivants identifiant la carte précisément. Quant au dernier, il permet après application de l’algorithme de Luhn (qui sert à générer les numéros) de valider que les précédents chiffres sont bons, ce qui est utilisé par les sites internet pour vous indiquer en temps réel si le numéro que vous avez entré est correct.


Commentaires préférés (3)

Tout comme:

Votre compte apparaissant sur votre RIB: qui contient votre code banque + code guichet + numero compte + clé.

l’IBAN (International Bank Account Number) de votre compte qui contient le code pays + code national de votre compte (celui cité au dessus) + clé.

Le BIC a aussi une signification. C’est le Bank Identifier Code: Code Banque + Code Pays + Code localisation + (optionnel) Code succursale.

Source: je travaille sur des systèmes bancaire connecté au réseau SWIFT :) le fameux que l’Europe voulait couper aux Russes.

Les numéros tels que le numéro de carte bancaire sont souvent composés de plusieurs « sous-numéros » qui stipulent des informations précises.

On pourrait parler du code ISBN pour les livres, du code VIN pour les voitures (numéro de chassis), du numéro de SIRET (des entreprises), le RIB, comme indiqué par @BenBou63, parfois, les numéros de devis et de facture mais aussi plus simplement encore les codes postaux, et bien sûr l’infâme numéro de sécurité sociale (code NIR) qui contient généralement (mais il existe plein de cas particuliers) :
- un chiffre pour le sexe ;
- deux chiffres pour les deux derniers chiffres de l’année naissance ;
- deux pour le mois ;
- deux pour le département (bien que là, on puisse trouver une lettre, pour les corses, comme le souligne @dipisoft, ou même trois chiffres pour l’outre-mer) ;
- trois chiffres pour le code INSEE de la commune (ou deux, pour l’outre-mer),
- trois chiffres pour le numéro d’ordre de naissance (pour ce même mois et cette même commune)
- et enfin, deux chiffres qui servent de clé de contrôle, comme l’a très justement pressenti @ShaeGal (et pour la Corse, du coup, les lettres A et B sont remplacées par des zéros)

Les clés de contrôles sont calculées à partir des précédents chiffres du code, à l’aide d’une formule mathématique reposant sur des opérations arithmétiques simple (addition, soustraction, multiplication division) et parfois sur des modulo (reste d’une division), comme c’est le cas de l’algorithme de Luhn. Ces clés de contrôle ne détiennent donc pas d’information à proprement parler, mais permettent de savoir que le reste du numéro est statistiquement valable (non erroné / non falsifié).

L’anecdote sous-entend que ceci permet « aux sites internet » d’indiquer en temps réel si le numéro est correct, mais selon moi, les clés de contrôles sont surtout utiles en mode déconnecté (donc, sans accès au réseau). Il est ainsi possible pour n’importe quel automatisme d’accepter ou de refuser un numéro ISBN, un numéro de sécu ou un numéro de CB en effectuant une simple analyse du numéro lui-même, et en le comparant à la clé de contrôle, sans faire aucun échange réseau.

Comme @zipohi l’évoque, il s’agit d’un contrôle de saisie statistique qui va simplement réduire le risque d’erreur. Il pourra arriver parfois qu’une saisie invalide donne, par (mal)chance une clé de contrôle valable. Le numéro ne sera pas fonctionnel, mais ceci ne se saura que « plus tard » dans le flux de traitement, et l’auteur de la saisie ne pourra en être informé que de manière indirecte après un certain laps de temps.

a écrit : Mais vu qu'il n'y a qu un seul chiffre de contrôle, cela voudrait dire que l'algorithme produit un faux positif 1 fois sur 10? Ou peut être y a t il quelque chose de plus profond dans l'algorithme qui m échappe? y a t il un matheux dans l assistance pour répondre à cette question? je ne suis pas matheux mais je travaille dans une industrie qui utilise des protocoles de communication avec des clés de chiffrements. Il n'a pas de notion de faux positif, la clé est un calcul qui est fait des 2 côtés (émetteur et récepteur). Le résultat de calcul doit être identique des 2 côtés, sinon le fichier reçu différe de celui qui a été transmis, et on peut donc déceler un défaut de transmission. Par exemple, tu transmets un fichier avec 1000 caractères + une clé, calculée par l'émetteur. Le récepteur reçoit les 1000 caractères, en calcule lui même la clé, puis il compare avec la clé qu'il a reçu. Si un des 1000 caractères à ête mal reçu (il manque une virgule), le récepteur calculera une clé différente. Il existe beaucoup d'algorithmes (de formule) pour calculer la clé, leur but est de calculer des clés complètement différentes pour des caractères de base proches, il ya plus de chances de calculer 2 clés identiques à partir de caractères très éloignés qu'à partir de caractères proches. Pour illustrer aaaaaa et 99999 peuvent avoir des clés identiques (ce n'est pas grave car le risque de recevoir 99999 à la place de aaaaaa est négligeable), mais pas aaaaaa et abaaaa (le risque est plus élevé).
Les clés sont donc présentes partout, et pas uniquement pour des identifiants. Elles sont devenus indispensables des qu'on parle de cybersecurite et même sans en parler, leur usage est généralisé.


Tous les commentaires (22)

Il me semble que la clé du numéro de sécurité sociale utilise le même système que l'algorithme cité dans l'anecdote.

Tout comme:

Votre compte apparaissant sur votre RIB: qui contient votre code banque + code guichet + numero compte + clé.

l’IBAN (International Bank Account Number) de votre compte qui contient le code pays + code national de votre compte (celui cité au dessus) + clé.

Le BIC a aussi une signification. C’est le Bank Identifier Code: Code Banque + Code Pays + Code localisation + (optionnel) Code succursale.

Source: je travaille sur des systèmes bancaire connecté au réseau SWIFT :) le fameux que l’Europe voulait couper aux Russes.

Mais vu qu'il n'y a qu un seul chiffre de contrôle, cela voudrait dire que l'algorithme produit un faux positif 1 fois sur 10? Ou peut être y a t il quelque chose de plus profond dans l'algorithme qui m échappe? y a t il un matheux dans l assistance pour répondre à cette question?

a écrit : Il me semble que la clé du numéro de sécurité sociale utilise le même système que l'algorithme cité dans l'anecdote. Non, ne serait-ce que pour le traitement du cas particulier des personnes nées en Corse depuis 1976 et pour lesquelles le NIR est alphanumérique (contient 2A ou 2B).

Les numéros tels que le numéro de carte bancaire sont souvent composés de plusieurs « sous-numéros » qui stipulent des informations précises.

On pourrait parler du code ISBN pour les livres, du code VIN pour les voitures (numéro de chassis), du numéro de SIRET (des entreprises), le RIB, comme indiqué par @BenBou63, parfois, les numéros de devis et de facture mais aussi plus simplement encore les codes postaux, et bien sûr l’infâme numéro de sécurité sociale (code NIR) qui contient généralement (mais il existe plein de cas particuliers) :
- un chiffre pour le sexe ;
- deux chiffres pour les deux derniers chiffres de l’année naissance ;
- deux pour le mois ;
- deux pour le département (bien que là, on puisse trouver une lettre, pour les corses, comme le souligne @dipisoft, ou même trois chiffres pour l’outre-mer) ;
- trois chiffres pour le code INSEE de la commune (ou deux, pour l’outre-mer),
- trois chiffres pour le numéro d’ordre de naissance (pour ce même mois et cette même commune)
- et enfin, deux chiffres qui servent de clé de contrôle, comme l’a très justement pressenti @ShaeGal (et pour la Corse, du coup, les lettres A et B sont remplacées par des zéros)

Les clés de contrôles sont calculées à partir des précédents chiffres du code, à l’aide d’une formule mathématique reposant sur des opérations arithmétiques simple (addition, soustraction, multiplication division) et parfois sur des modulo (reste d’une division), comme c’est le cas de l’algorithme de Luhn. Ces clés de contrôle ne détiennent donc pas d’information à proprement parler, mais permettent de savoir que le reste du numéro est statistiquement valable (non erroné / non falsifié).

L’anecdote sous-entend que ceci permet « aux sites internet » d’indiquer en temps réel si le numéro est correct, mais selon moi, les clés de contrôles sont surtout utiles en mode déconnecté (donc, sans accès au réseau). Il est ainsi possible pour n’importe quel automatisme d’accepter ou de refuser un numéro ISBN, un numéro de sécu ou un numéro de CB en effectuant une simple analyse du numéro lui-même, et en le comparant à la clé de contrôle, sans faire aucun échange réseau.

Comme @zipohi l’évoque, il s’agit d’un contrôle de saisie statistique qui va simplement réduire le risque d’erreur. Il pourra arriver parfois qu’une saisie invalide donne, par (mal)chance une clé de contrôle valable. Le numéro ne sera pas fonctionnel, mais ceci ne se saura que « plus tard » dans le flux de traitement, et l’auteur de la saisie ne pourra en être informé que de manière indirecte après un certain laps de temps.

a écrit : Mais vu qu'il n'y a qu un seul chiffre de contrôle, cela voudrait dire que l'algorithme produit un faux positif 1 fois sur 10? Ou peut être y a t il quelque chose de plus profond dans l'algorithme qui m échappe? y a t il un matheux dans l assistance pour répondre à cette question? je ne suis pas matheux mais je travaille dans une industrie qui utilise des protocoles de communication avec des clés de chiffrements. Il n'a pas de notion de faux positif, la clé est un calcul qui est fait des 2 côtés (émetteur et récepteur). Le résultat de calcul doit être identique des 2 côtés, sinon le fichier reçu différe de celui qui a été transmis, et on peut donc déceler un défaut de transmission. Par exemple, tu transmets un fichier avec 1000 caractères + une clé, calculée par l'émetteur. Le récepteur reçoit les 1000 caractères, en calcule lui même la clé, puis il compare avec la clé qu'il a reçu. Si un des 1000 caractères à ête mal reçu (il manque une virgule), le récepteur calculera une clé différente. Il existe beaucoup d'algorithmes (de formule) pour calculer la clé, leur but est de calculer des clés complètement différentes pour des caractères de base proches, il ya plus de chances de calculer 2 clés identiques à partir de caractères très éloignés qu'à partir de caractères proches. Pour illustrer aaaaaa et 99999 peuvent avoir des clés identiques (ce n'est pas grave car le risque de recevoir 99999 à la place de aaaaaa est négligeable), mais pas aaaaaa et abaaaa (le risque est plus élevé).
Les clés sont donc présentes partout, et pas uniquement pour des identifiants. Elles sont devenus indispensables des qu'on parle de cybersecurite et même sans en parler, leur usage est généralisé.

a écrit : Les numéros tels que le numéro de carte bancaire sont souvent composés de plusieurs « sous-numéros » qui stipulent des informations précises.

On pourrait parler du code ISBN pour les livres, du code VIN pour les voitures (numéro de chassis), du numéro de SIRET (des entreprises), le RIB, comme indiqué par @
BenBou63, parfois, les numéros de devis et de facture mais aussi plus simplement encore les codes postaux, et bien sûr l’infâme numéro de sécurité sociale (code NIR) qui contient généralement (mais il existe plein de cas particuliers) :
- un chiffre pour le sexe ;
- deux chiffres pour les deux derniers chiffres de l’année naissance ;
- deux pour le mois ;
- deux pour le département (bien que là, on puisse trouver une lettre, pour les corses, comme le souligne @dipisoft, ou même trois chiffres pour l’outre-mer) ;
- trois chiffres pour le code INSEE de la commune (ou deux, pour l’outre-mer),
- trois chiffres pour le numéro d’ordre de naissance (pour ce même mois et cette même commune)
- et enfin, deux chiffres qui servent de clé de contrôle, comme l’a très justement pressenti @ShaeGal (et pour la Corse, du coup, les lettres A et B sont remplacées par des zéros)

Les clés de contrôles sont calculées à partir des précédents chiffres du code, à l’aide d’une formule mathématique reposant sur des opérations arithmétiques simple (addition, soustraction, multiplication division) et parfois sur des modulo (reste d’une division), comme c’est le cas de l’algorithme de Luhn. Ces clés de contrôle ne détiennent donc pas d’information à proprement parler, mais permettent de savoir que le reste du numéro est statistiquement valable (non erroné / non falsifié).

L’anecdote sous-entend que ceci permet « aux sites internet » d’indiquer en temps réel si le numéro est correct, mais selon moi, les clés de contrôles sont surtout utiles en mode déconnecté (donc, sans accès au réseau). Il est ainsi possible pour n’importe quel automatisme d’accepter ou de refuser un numéro ISBN, un numéro de sécu ou un numéro de CB en effectuant une simple analyse du numéro lui-même, et en le comparant à la clé de contrôle, sans faire aucun échange réseau.

Comme @zipohi l’évoque, il s’agit d’un contrôle de saisie statistique qui va simplement réduire le risque d’erreur. Il pourra arriver parfois qu’une saisie invalide donne, par (mal)chance une clé de contrôle valable. Le numéro ne sera pas fonctionnel, mais ceci ne se saura que « plus tard » dans le flux de traitement, et l’auteur de la saisie ne pourra en être informé que de manière indirecte après un certain laps de temps.
Afficher tout
la clé de contrôle ne permet pas du tout de voir si la saisie est statistiquement valable, l'algorithme est appliquée et renvoie une valeur quelquesoient les valeurs saisies, et la comparaison des clés donne un résultat binaire, pas statistique. en plus, si le calcul n'est pas en temps réel, la clé n'a aucun intérêt, il suffirait de vérifier avec une bdd débarquée que les valeurs existent et sont bien attribuées. L'intérêt de la clé est justement de pouvoir vérifier immédiatement et localement

Il y a également le même système pour l'identification des wagons et voitures du parc ferroviaire. Le dernier chiffre valide le reste

a écrit : la clé de contrôle ne permet pas du tout de voir si la saisie est statistiquement valable, l'algorithme est appliquée et renvoie une valeur quelquesoient les valeurs saisies, et la comparaison des clés donne un résultat binaire, pas statistique. en plus, si le calcul n'est pas en temps réel, la clé n'a aucun intérêt, il suffirait de vérifier avec une bdd débarquée que les valeurs existent et sont bien attribuées. L'intérêt de la clé est justement de pouvoir vérifier immédiatement et localement Afficher tout Peut-être que l'expression "statistiquement valable" n'est pas appropriée, mais je cherchais à rebondir sur le "1 fois sur 10" évoqué par @zipohi.
À partir du moment où la clé de contrôle est sur un seul chiffre, comme pour le numéro de CB, ça veut dire que, pour une saisie donnée, lors de la vérification de la clé de contrôle, il y a une chance sur 10 que le numéro soit considéré comme correctement saisi, alors que non.
Je n'ai pas compris pourquoi tu fais un laïus sur le temps réel. Moi c'est le côté "internet" que je ne trouvais pas forcément potentiellement trompeur dans l'anecdote, dans la mesure ou les clés de contrôle permettent aussi et surtout un contrôle de saisie sans échange réseau.
Précision : je distingue la clé de contrôle présente à la fin d'un code de la somme de contrôle (checksum) que tu décris dans ton précédent message, et dont le fonctionnement prend tout son sens lors des échanges de données à travers le réseau pour le coup.

a écrit : Peut-être que l'expression "statistiquement valable" n'est pas appropriée, mais je cherchais à rebondir sur le "1 fois sur 10" évoqué par @zipohi.
À partir du moment où la clé de contrôle est sur un seul chiffre, comme pour le numéro de CB, ça veut dire que, pour une saisie donnée,
lors de la vérification de la clé de contrôle, il y a une chance sur 10 que le numéro soit considéré comme correctement saisi, alors que non.
Je n'ai pas compris pourquoi tu fais un laïus sur le temps réel. Moi c'est le côté "internet" que je ne trouvais pas forcément potentiellement trompeur dans l'anecdote, dans la mesure ou les clés de contrôle permettent aussi et surtout un contrôle de saisie sans échange réseau.
Précision : je distingue la clé de contrôle présente à la fin d'un code de la somme de contrôle (checksum) que tu décris dans ton précédent message, et dont le fonctionnement prend tout son sens lors des échanges de données à travers le réseau pour le coup.
Afficher tout
Je suppose, sans la moindre certitude, qu’il n’est pas possible de retomber sur la même clé de vérification si ton nombre ne comporte qu’une ou deux erreurs de frappe. Je pense qu’il est mathématiquement possible de faire une formule où les nombres possédant la même clé de vérification auraient a minima 3 chiffres différents… Et là la probabilité de passer entre les mailles deviendrait infime…

a écrit : Les numéros tels que le numéro de carte bancaire sont souvent composés de plusieurs « sous-numéros » qui stipulent des informations précises.

On pourrait parler du code ISBN pour les livres, du code VIN pour les voitures (numéro de chassis), du numéro de SIRET (des entreprises), le RIB, comme indiqué par @
BenBou63, parfois, les numéros de devis et de facture mais aussi plus simplement encore les codes postaux, et bien sûr l’infâme numéro de sécurité sociale (code NIR) qui contient généralement (mais il existe plein de cas particuliers) :
- un chiffre pour le sexe ;
- deux chiffres pour les deux derniers chiffres de l’année naissance ;
- deux pour le mois ;
- deux pour le département (bien que là, on puisse trouver une lettre, pour les corses, comme le souligne @dipisoft, ou même trois chiffres pour l’outre-mer) ;
- trois chiffres pour le code INSEE de la commune (ou deux, pour l’outre-mer),
- trois chiffres pour le numéro d’ordre de naissance (pour ce même mois et cette même commune)
- et enfin, deux chiffres qui servent de clé de contrôle, comme l’a très justement pressenti @ShaeGal (et pour la Corse, du coup, les lettres A et B sont remplacées par des zéros)

Les clés de contrôles sont calculées à partir des précédents chiffres du code, à l’aide d’une formule mathématique reposant sur des opérations arithmétiques simple (addition, soustraction, multiplication division) et parfois sur des modulo (reste d’une division), comme c’est le cas de l’algorithme de Luhn. Ces clés de contrôle ne détiennent donc pas d’information à proprement parler, mais permettent de savoir que le reste du numéro est statistiquement valable (non erroné / non falsifié).

L’anecdote sous-entend que ceci permet « aux sites internet » d’indiquer en temps réel si le numéro est correct, mais selon moi, les clés de contrôles sont surtout utiles en mode déconnecté (donc, sans accès au réseau). Il est ainsi possible pour n’importe quel automatisme d’accepter ou de refuser un numéro ISBN, un numéro de sécu ou un numéro de CB en effectuant une simple analyse du numéro lui-même, et en le comparant à la clé de contrôle, sans faire aucun échange réseau.

Comme @zipohi l’évoque, il s’agit d’un contrôle de saisie statistique qui va simplement réduire le risque d’erreur. Il pourra arriver parfois qu’une saisie invalide donne, par (mal)chance une clé de contrôle valable. Le numéro ne sera pas fonctionnel, mais ceci ne se saura que « plus tard » dans le flux de traitement, et l’auteur de la saisie ne pourra en être informé que de manière indirecte après un certain laps de temps.
Afficher tout
exactement, ce genre de clefs ne sert pas a empêcher la fraude mais uniquement l'erreur de saisie.
tout comme le bit de parité en fin d'une série de bit est une clé de contrôle pour les bits de cette suite. de plus comme tu le fais remarquer c'est un contrôle statistiques, ça permet de vérifier si une donnée est "plausible" mais pas si elle est bonne

a écrit : Peut-être que l'expression "statistiquement valable" n'est pas appropriée, mais je cherchais à rebondir sur le "1 fois sur 10" évoqué par @zipohi.
À partir du moment où la clé de contrôle est sur un seul chiffre, comme pour le numéro de CB, ça veut dire que, pour une saisie donnée,
lors de la vérification de la clé de contrôle, il y a une chance sur 10 que le numéro soit considéré comme correctement saisi, alors que non.
Je n'ai pas compris pourquoi tu fais un laïus sur le temps réel. Moi c'est le côté "internet" que je ne trouvais pas forcément potentiellement trompeur dans l'anecdote, dans la mesure ou les clés de contrôle permettent aussi et surtout un contrôle de saisie sans échange réseau.
Précision : je distingue la clé de contrôle présente à la fin d'un code de la somme de contrôle (checksum) que tu décris dans ton précédent message, et dont le fonctionnement prend tout son sens lors des échanges de données à travers le réseau pour le coup.
Afficher tout
la clef n'est pas sur un seul chiffre sur la CB
c'est une addition modulo 10
l'algorithme de luhn est justement un checksum
(le checksum n'est pas obligatoirement ou uniquement un XOR coulissant)

a écrit : Je suppose, sans la moindre certitude, qu’il n’est pas possible de retomber sur la même clé de vérification si ton nombre ne comporte qu’une ou deux erreurs de frappe. Je pense qu’il est mathématiquement possible de faire une formule où les nombres possédant la même clé de vérification auraient a minima 3 chiffres différents… Et là la probabilité de passer entre les mailles deviendrait infime… Afficher tout pas tout a fait
génère un nombre au pif qui comporte la suite 90 .
inverse le 0 et le 9 , c'est a dire met 09 a la place de 90 dans ta suite est tu verras que la clef restera identique

a écrit : Non, ne serait-ce que pour le traitement du cas particulier des personnes nées en Corse depuis 1976 et pour lesquelles le NIR est alphanumérique (contient 2A ou 2B). Non, au moment de calculer la clé du n° de sécu, le système remplace 2A par 19 et 2B par 18
on aurait pu aussi évoquer les département 69M ou 69D, mais pour "Lyon métropole", et pour le "Rhône" on continue à utiliser "69" aussi bien pour l'un que pour l'autre

a écrit : la clef n'est pas sur un seul chiffre sur la CB
c'est une addition modulo 10
l'algorithme de luhn est justement un checksum
(le checksum n'est pas obligatoirement ou uniquement un XOR coulissant)
À tes souhaits

a écrit : Peut-être que l'expression "statistiquement valable" n'est pas appropriée, mais je cherchais à rebondir sur le "1 fois sur 10" évoqué par @zipohi.
À partir du moment où la clé de contrôle est sur un seul chiffre, comme pour le numéro de CB, ça veut dire que, pour une saisie donnée,
lors de la vérification de la clé de contrôle, il y a une chance sur 10 que le numéro soit considéré comme correctement saisi, alors que non.
Je n'ai pas compris pourquoi tu fais un laïus sur le temps réel. Moi c'est le côté "internet" que je ne trouvais pas forcément potentiellement trompeur dans l'anecdote, dans la mesure ou les clés de contrôle permettent aussi et surtout un contrôle de saisie sans échange réseau.
Précision : je distingue la clé de contrôle présente à la fin d'un code de la somme de contrôle (checksum) que tu décris dans ton précédent message, et dont le fonctionnement prend tout son sens lors des échanges de données à travers le réseau pour le coup.
Afficher tout
ah bah j'ai l'impression qu'on voulait dire la même chose en ayant tous les 2 des difficultés à l'exprimer !
et tu as raison j'ai confondu la clé et la somme de contrôle. quelqu'un pour m'expliquer la différence ?

a écrit : pas tout a fait
génère un nombre au pif qui comporte la suite 90 .
inverse le 0 et le 9 , c'est a dire met 09 a la place de 90 dans ta suite est tu verras que la clef restera identique
Alors non. La formule de Luhn est justement conçue pour détecter l’inversion de chiffres, qui est une erreur de saisie coiffante. Cela est fait en multipliant par deux un chiffre sur deux.
Le système américain (aba ou routing number) utilise un algo similaire.

a écrit : Non, ne serait-ce que pour le traitement du cas particulier des personnes nées en Corse depuis 1976 et pour lesquelles le NIR est alphanumérique (contient 2A ou 2B). Certains RIB contiennent aussi des chiffres et des lettres (la poste, crédit lyonnais, etc) qui sont converties lors du processus de calcul de la clé RIB...ensuite le modulo9 de l'ensemble des chiffres est calculé et donne la clé rib..

a écrit : Non, au moment de calculer la clé du n° de sécu, le système remplace 2A par 19 et 2B par 18
on aurait pu aussi évoquer les département 69M ou 69D, mais pour "Lyon métropole", et pour le "Rhône" on continue à utiliser "69" aussi bien pour l'un que pour l'autre
Il n'empêche que c'est bel et bien un cas particulier donc on ne peut pas dire que "la clé du numéro de sécurité sociale utilise le même système que l'algorithme cité dans l'anecdote" (propos de ShaeGal).

Quand au calcul de ladite clé il est aussi différent (modulo de 97 pour le NIR vs. modulo de 9 pour le RIB d'après @Kermitou)

a écrit : Il n'empêche que c'est bel et bien un cas particulier donc on ne peut pas dire que "la clé du numéro de sécurité sociale utilise le même système que l'algorithme cité dans l'anecdote" (propos de ShaeGal).

Quand au calcul de ladite clé il est aussi différent (modulo de 97 pour
le NIR vs. modulo de 9 pour le RIB d'après @Kermitou) Afficher tout
Bon en gros, si j'ai bien compris, notre identité, c'est un tas de chiffres incompréhensible pour un non-initié.

" faites vos jeux, rien ne va plus" Arf, perdu, vos identifiants ont été piratés et c'est de votre faute!

je me pose une question, comment es-ce possible de se faire voler son identité avec ces systèmes informatiques d'une ultraperformance inviolable sur la vie d'ma reum??
C'est une question à la con, hein

-SAUVAGE!!! Tu répond quoi?
-Je sais pas! Merci?