Menu

Luhn-algoritme: waarom kaartnummers eindigen op een controlecijfer

Het Luhn-algoritme is een mod-10-controlesom achter het laatste cijfer van een kaartnummer. Leer hoe je het met de hand berekent, wat het opvangt en wat het niet kan bewijzen.

Gepubliceerd

  • testdata
  • betalingen
  • Luhn

Het Luhn-algoritme is de reden dat een kaartnummer eindigt op een cijfer dat willekeurig lijkt. Het is een controlesom — een kleine rekenkundige samenvatting van elk cijfer dat eraan voorafgaat — en het is de meest voorkomende geautomatiseerde test waaraan een kaartnummer moet voldoen voordat er iets anders gebeurt. Het werd in de jaren vijftig bij IBM bedacht door Hans Peter Luhn en werd later een conventie voor betaalkaarten via de internationale standaard die de nummering van kaarten regelt.

Dit artikel legt uit waar het controlecijfer voor dient, hoe je het op papier uitrekent, waarom het de meeste typefouten opvangt, en waarom het halen ervan veel minder betekent dan mensen aannemen.

Wat het Luhn-algoritme doet

Neem een kaartnummer, leg het laatste cijfer apart, en laat de overige cijfers door een vaste procedure gaan. Het resultaat bepaalt wat het afsluitende cijfer moet zijn. Een nummer wordt geaccepteerd wanneer het afsluitende cijfer consistent is met alles ervoor.

Niets in die procedure betrekt een bank, een accountlijst of een geheim erbij. Het is rekenkunde die in studieboeken is gepubliceerd, in bijna elke programmeertaal is nagebouwd, en in een fractie van een milliseconde te berekenen is. Ze beantwoordt precies één nauwe vraag: bevat deze reeks een duidelijke overtypfout?

Die nauwheid is makkelijk te vergeten. Omdat de controlesom de meest zichtbare geautomatiseerde test in een afrekenformulier is, gaan mensen geloven dat ze meer zegt dan ze doet.

Hoe bereken je een controlecijfer met de hand?

De procedure loopt van rechts naar links over de cijfers die overblijven nadat het afsluitende cijfer is verwijderd.

  1. Schrijf de cijfers op en nummer hun posities vanaf rechts, beginnend bij één.
  2. Verdubbel elk cijfer op een even positie.
  3. Als een verdubbelde waarde boven negen uitkomt, trek er dan negen van af — hetzelfde als de twee cijfers van het resultaat bij elkaar optellen.
  4. Tel alle waarden bij elkaar op.
  5. Bepaal hoeveel je zou moeten toevoegen om het volgende veelvoud van tien te bereiken. Dat bedrag is het controlecijfer.

Een kort voorbeeld maakt het concreet. Neem de vijf cijfers 1, 2, 3, 4 en 5 als de romp van een langer nummer en nummer ze vanaf rechts: de 5 staat op positie één, de 4 op positie twee, de 3 op positie drie, de 2 op positie vier en de 1 op positie vijf. Het verdubbelen van de even posities maakt van de 4 een 8 en van de 2 een 4. De waarden zijn dan 1, 4, 3, 8 en 5, die samen 21 geven. Het volgende veelvoud van tien is 30, dus het controlecijfer is 9 en de voltooide reeks eindigt op 9.

Dat met de hand doen voor een kaartnummer van volledige lengte is vervelend maar nooit dubbelzinnig. Software doet het door de reeks vanaf het einde te doorlopen, wat ook de reden is dat een implementatie die vanaf de verkeerde kant begint, volkomen goede nummers afwijst.

Waarom vangt verdubbelen verwisselde cijfers op?

De verdubbelingsregel is niet willekeurig. Ze laat het gewicht van elk cijfer afhangen van zijn positie, zodat het verwisselen van twee buren doorgaans het totaal verandert.

Dat is belangrijk omdat de twee meest voorkomende menselijke fouten in een numeriek veld het verkeerd intypen van één cijfer en het verwisselen van twee aangrenzende cijfers zijn. Eén verkeerd cijfer verschuift de som met een bedrag dat niet nul is, dus de controlesom mislukt bijna altijd. Een verwisseling tussen buren verschuift de som ook, omdat één van het paar werd verdubbeld en de andere niet.

Bijna, niet altijd. Een paar verwisselingen is onzichtbaar voor deze controle. De klassieke blinde vlek is het paar nul en negen naast elkaar: negen verdubbelen en het resultaat met negen verminderen levert negen op, dus die twee kunnen van plaats wisselen zonder het totaal te veranderen. Andere paren gedragen zich hetzelfde. De nauwkeurige beschrijving van de controle is dan ook dat ze elke fout van één cijfer opvangt en de meeste, maar niet alle, aangrenzende verwisselingen.

Wat het controlecijfer je niet kan vertellen

Het kan niet zeggen of een nummer echt is. Niets in de rekenkunde verwijst naar een uitgever, dus elke prefix kan met willekeurige middelste cijfers worden gecombineerd en er kan een geldig afsluitend cijfer worden berekend dat past.

Het kan niet zeggen dat een account open is, dat een kaart niet is geblokkeerd, of dat de persoon die het nummer intypt de kaart in handen heeft. Elk van die vragen vereist een autorisatieverzoek aan de uitgever, precies de handeling die een testomgeving moet vermijden.

Het kan ook niet instaan voor de vervaldatum, de naam van de kaarthouder of de beveiligingscode. Die velden staan naast het controlecijfer met eigen regels, en een nummer dat aan de controlesom voldoet, kan worden gecombineerd met een datum die al is verstreken en een code die nergens mee overeenkomt.

Dit is de eerlijke beschrijving van wat de generator op deze site teruggeeft: elke waarde is structureel geldig en consistent met deze controlesom, en elk ervan is een nummer dat nooit aan iemand is uitgegeven.

Waar dezelfde controlesom nog meer opduikt

Betaalkaarten zijn de bekendste gebruiker van deze methode, niet de enige. Nummeringsschema’s die een goedkope typefoutbeveiliging nodig hebben, grijpen vaak naar dezelfde openbare rekenkunde, waaronder verschillende nationale identificatienummers, allerlei loyaliteits- en cadeaukaartsystemen, en diverse interne identificatiecodes.

Dat hergebruik heeft een praktische consequentie. Een gedeelde helper die een geslaagde controlesom als bewijs van “creditcard” behandelt, zal al het andere dat er toevallig aan voldoet verkeerd classificeren. Noem de routine naar wat ze doet — een modulus-tien-controlesom — en niet naar het domein waar je haar voor het eerst tegenkwam.

Voor ontwikkelaars: volgorde van controles en veelvoorkomende valkuilen

De volgorde van validatie is belangrijker dan mensen verwachten, en de controlesom is niet de juiste plek om te beginnen.

Controleer eerst de lengte, want de procedure heeft geen mening over hoeveel cijfers ze krijgt; een fragment van vijf cijfers kan controlesomconsistent zijn en toch nutteloos. Controleer daarna de tekenset, zodat letters, losse spaties en scheidingstekens worden geweigerd voordat er rekenkunde draait. Bereken daarna de controlesom, en probeer pas dan een netwerk te herkennen aan de prefix.

Drie valkuilen duiken steeds opnieuw op:

  • Een voorloopnul als onbelangrijk behandelen. Kaartnummers zijn strings, geen gehele getallen, en een numerieke parse kan stilletjes een cijfer laten vallen, wat een controlesomfout oplevert die niets te maken heeft met wat de gebruiker typte.
  • De verdubbelingsronde vanaf links uitvoeren. Positie wordt vanaf rechts bepaald, dus richting is onderdeel van de specificatie en geen implementatiedetail.
  • Een mislukte controlesom rapporteren als een geweigerde kaart. Het betekent misvormde invoer, en de boodschap aan de gebruiker moet dat zeggen.

Voor testdata is het nuttige patroon om paren aan te houden: een nummer dat slaagt en hetzelfde nummer met één cijfer veranderd zodat het faalt. Dat geeft de suite een positief en een negatief geval die precies één teken van elkaar verschillen, wat een regressie in één oogopslag duidelijk maakt. De opmaakgids behandelt de lengte- en prefixregels die vóór de controlesom moeten draaien, en de validatiewalkthrough zet de hele reeks in de juiste volgorde.

Een controlesom controleren tegen een echte reeks

De snelste manier om intuïtie op te bouwen is een paar reeksen door de kaartnummersgenerator te halen. Genereer een batch, verander één cijfer met de hand en zie de controle mislukken; genereer opnieuw en merk op dat alleen het afsluitende cijfer beweegt terwijl alles ervoor vast blijft. De netwerkvergelijking is het lezen waard als volgende stap, omdat dezelfde rekenkunde zich anders gedraagt bij vijftien- en zestiencijferige schema’s en dat verschil handgeschreven helpers laat struikelen.

Volgende stappen

Schrijf je validatievolgorde op voordat je de code schrijft, met de controlesom op één na laatste, en bewaar één bewust beschadigde fixture voor elk geldig nummer in je suite. Wanneer je wilt zien hoe lengtes en prefixen samenspelen met het afsluitende cijfer, ga dan verder met de gids over het kaartnummerformaat.

Verder lezen

Handleidingen over Generator voor valse creditcardnummers (testkaarten)