CVV uitgelegd: waar de kaartbeveiligingscode voor dient

De korte code die op een betaalkaart gedrukt staat, is het veld waarover mensen aarzelen wanneer ze een kaart hardop voorlezen, en die aarzeling is precies het punt. Een CVV is een apart geheim dat alleen op het plastic leeft, niet in het nummer, niet in de vervaldatum, en niet in iets wat een dief uit een bonnetje zou kunnen reconstrueren. Hij werd toegevoegd omdat betalingen zonder fysieke kaart enig bewijs nodig hadden dat de persoon die de gegevens intypt de kaart daadwerkelijk in handen had.

Dit artikel legt uit wat de code is, waarom de lengte per netwerk verschilt, waarom betaalregels verbieden hem te bewaren, en waar je op moet letten wanneer je een formulier bouwt of test dat erom vraagt.

Wat de beveiligingscode is en waar hij gedrukt staat

Voor de meeste netwerken is de code drie cijfers, gedrukt op de achterkant van de kaart, hetzij binnen de handtekeningstrook, hetzij direct ernaast. American Express zet vier cijfers op de voorkant, boven de laatste groep van het kaartnummer.

De waarde wordt door de uitgever gegenereerd wanneer de kaart wordt gemaakt. Hij is niet afgeleid van het kaartnummer, het is geen controlesom, en hij kan niet worden berekend uit iets anders dat op de kaart staat. Als je de code kwijtraakt, kun je hem niet met rekenkunde herstellen; de uitgever moet opnieuw uitgeven.

Documentatie gebruikt er meerdere namen voor, en de nummering in die namen is betekenisvol in plaats van decoratief. De gewone term beschrijft gegevens die in de magneetstrip of de chip zijn gecodeerd, terwijl de versie die als twee wordt aangeduid de gedrukte waarde is die een klant voorleest. Een test van een terminal voor fysieke kaarten en een test van een afrekenpagina raken dus verschillende velden, ook al klinken de namen inwisselbaar.

Waarom is de code op sommige kaarten drie cijfers en op andere vier?

Het verschil komt uit het nummeringsplan dat elk netwerk heeft gekozen, niet uit een beveiligingsonderscheid. Een code van vier cijfers is in geen enkele betekenisvolle zin sterker dan een code van drie cijfers; beide zijn kort genoeg dat raden niet het dreigingsmodel is. De lengte is simpelweg onderdeel van de specificatie van het netwerk, net zoals de kaartnummers een verschillend aantal cijfers gebruiken.

Voor iedereen die een formulier bouwt, genereert dat ene feit het meeste van de bugs op dit gebied. Een veld dat hard is gecodeerd op drie tekens kapt een American Express-code af zonder de gebruiker iets te zeggen, en een validator die op drie cijfers staat, wijst een legitieme kaart af. De pragmatische aanpak is om de gebruiker eerst naar het merk te vragen, of het uit het nummer te detecteren, en het veld daarop af te stemmen — met een bovengrens die nog steeds absurde invoer weigert.

Wat bewijst de code, en wat niet?

Bij een transactie zonder fysieke kaart kan de handelaar de kaart niet zien, dus vraagt het betaalsysteem om iets wat iemand die de kaart vasthoudt kan voorlezen. Het nummer en de vervaldatum hadden van een oude factuur of een gelekt databestand kunnen worden gekopieerd; de gedrukte code niet, want die is nergens anders opgeschreven.

Dat maakt het een bescheiden maar reëel obstakel voor gelegenheidsfraude, en daarom is het veld niet decoratief. Netwerken behandelen de code als bewijs dat een transactie aan een hogere verificatiedrempel voldeed, en handelaars die hem goed verzamelen worden anders behandeld dan degenen die dat niet doen wanneer fraude wordt betwist. De precieze voorwaarden van die verschuiving van aansprakelijkheid horen bij de netwerken; de praktische les voor wie een formulier bouwt is simpelweg dat het veld moet worden verzameld, niet gesimuleerd.

Wat de code niet bewijst, is dat de kaart echt is of dat het account in goede staat is. Een geraden waarde in de juiste vorm slaagt onmiddellijk voor elke client-side controle, omdat een formulier geen geheim kan verifiëren dat het niet kan zien. Alleen een autorisatieverzoek bij de uitgever kan die vraag beantwoorden.

Waarom verbieden kaartregels het bewaren van de code?

Dit is de regel die engineeringteams het meest verrast. Volgens de beveiligingsstandaard van de kaartindustrie wordt de beveiligingscode geclassificeerd als gevoelige authenticatiegegevens. Hij mag worden gebruikt om een transactie te autoriseren, en mag na autorisatie niet worden bewaard — niet in een databasekolom, niet in een logbestand, niet in een spreadsheet, niet in een bericht op een wachtrij die een worker tien seconden later verwerkt.

De redenering is eenvoudig. Een opgeslagen code is een opgeslagen betaalreferentie. Als een datalek kaartnummers blootlegt, heeft de aanvaller nog iets extra’s nodig om ze online te gebruiken; als het de codes erbij blootlegt, worden de nummers onmiddellijk bruikbaar.

Bij een review zien de fouten er zelden uit als bewuste keuzes:

• Een kolom die aan de ordertabel is toegevoegd voor één debugsessie en nooit is verwijderd.
• Middleware voor requestlogging die de hele ingediende body vastlegt, code inbegrepen, in een aggregator met zwakkere toegangscontroles dan het betaalsysteem.
• Een foutrapporteur die de mislukte formulierpayload aan elke uitzondering hangt.
• Een wachtrij voor nieuwe pogingen die het oorspronkelijke afschrijfverzoek intact houdt zodat het kan worden herhaald.

Elk daarvan is een compliancefout, en geen ervan ziet er op het moment van schrijven als zodanig uit.

Een beveiligingscodeveld foutloos invullen

Het meeste van de moeilijkheid hier is typen en niet beveiliging, en de lastige gevallen zijn voorspelbaar genoeg om op te ontwerpen:

1. Een code die langer is dan het veld. Iemand plakt vier cijfers in een vak van drie tekens. Kap stil af of toon een melding, maar kies één gedrag en pas het consistent toe.
2. Niet-numerieke invoer. Letters, een spatie, een koppelteken uit een gekopieerd blok. Het veld moet ze weigeren zonder te wissen wat de gebruiker al heeft getypt.
3. Voorloopnullen. Een code die met nul begint is toegestaan en mag niet worden weggenormaliseerd door de waarde als getal te parsen.
4. Maskeren. De cijfers verbergen terwijl ze worden getypt lijkt geruststellend, maar controleer dat het autofill niet breekt of de browser het hele afrekenproces als inlogscherm laat behandelen.
5. Mobiele toetsenborden. Een numeriek toetsenblok is sneller in gebruik, wat uitmaakt bij een veld dat mensen typen terwijl ze de kaart in de andere hand houden.

Voor ontwikkelaars: de code buiten logs en opslag houden

De engineeringdiscipline hier is aftrekken. De veiligste omgang met gevoelige authenticatiegegevens is ze op geen enkel moment in een systeem te hebben, behalve op het moment van autorisatie.

Begin met het beoordelen van wat je logginglaag daadwerkelijk vastlegt. Een framework dat requestbodies standaard logt, legt de code vast, en de logbestemming is vaak een dienst van derden met andere toegangsregels. Als de code je server helemaal niet bereikt — omdat een gehost betaalveld hem rechtstreeks verzamelt — verdwijnt het probleem, en dat is de sterkste optie die er is.

Waar je de waarde wel verwerkt, behandel je haar als vluchtig. Voeg haar niet toe aan een modelobject dat naar een auditrij wordt geserialiseerd, neem haar niet op in een payload voor nieuwe pogingen, en laat een uitzonderingshandler haar niet aan een rapport hangen. Schrijf een test die na een run je loguitvoer doorzoekt en faalt als er een codevormige waarde opduikt; die ene controle vangt het merendeel van onbedoelde bewaring.

Kijk daarna naar je testdata. Alles wat het veld automatisch vult, moet uit synthetische waarden komen, met dezelfde zorg beoordeeld als elke andere betaalfixture. De PCI DSS-notities behandelen de bredere regels over wat in een testomgeving mag leven, en de checklist voor betaalformulieren plaatst dit veld in de reeks stromen die voor de lancering de moeite waard zijn om te oefenen.

Testkaarten en hun plaatsvervangende codes

Een gegenereerde kaart heeft een code nodig om het veld te vullen, en die waarde is een plaatsvervanger op dezelfde manier als de rest van de kaart. Hij heeft de juiste lengte en de juiste tekenset, en komt overeen met geen enkel geheim dat een uitgever bezit.

Dat is de nauwkeurige manier om alles te beschrijven wat de generator op deze site teruggeeft: structureel geldige data die nooit is uitgegeven. Een plaatsvervangende code laat een demo of een stagingtest compleet lijken, en zal nergens iets autoriseren.

Volgende stappen

Controleer één formulier dat je bezit op drie dingen, in deze volgorde: of het veld zich aanpast aan de codelengte van het netwerk, of de waarde in een log of tabel terechtkomt, en of de foutmeldingen een verkeerde lengte onderscheiden van een niet-ondersteund teken. Voor een nummer om bij het veld te gebruiken, gebruik je de kaartnummersgenerator, en voor de datum ernaast behandelt de gids over vervaldatums de grensvoorwaarden.