Der CVV erklärt in einem Satz: Es ist der kurze Zifferncode, der auf der Karte selbst gedruckt steht und der bei einer Zahlung ohne Karte beweist, dass die Person am anderen Ende die Karte physisch vor sich hat. Er ist damit der einzige Bestandteil einer Kartenzahlung, der weder aus der Kartennummer berechnet werden kann noch sich aus anderen Kundendaten erschließen lässt. Genau diese Eigenschaft macht ihn wertvoll für die Betrugsabwehr und gleichzeitig zum empfindlichsten Datum im gesamten Zahlungsvorgang.
Dieser Beitrag erklärt, wo der Code gedruckt wird, warum er je nach Netzwerk drei oder vier Stellen hat, was er tatsächlich beweist und warum Aufsichtsregeln verlangen, ihn nach der Autorisierung nirgends mehr aufzubewahren.
Was der Sicherheitscode ist und wo er gedruckt steht
Auf den meisten Karten steht der Code auf der Rückseite, im oder direkt neben dem Unterschriftsfeld. Bei diesen Karten umfasst er drei Ziffern. Bei American Express steht er auf der Vorderseite, oberhalb der letzten Gruppe der Kartennummer, und umfasst vier Ziffern.
Der Code wird vom Herausgeber beim Herstellen der Karte erzeugt. Er wird nicht aus der Kartennummer berechnet, er ist keine Prüfziffer und er lässt sich aus dem Ablaufdatum oder dem Namen des Karteninhabers nicht ableiten. Das ist der Kern seiner Nützlichkeit: Wer eine Kartennummer und ein Ablaufdatum aus einem Datenleck besitzt, hat noch keinen Zahlungsvorgang in der Hand. Erst mit dem gedruckten Code wird aus dem Datensatz eine verwendbare Zahlungsreferenz.
Verwirrend ist die Namensvielfalt in der Dokumentation. Je nach Netzwerk und Kontext heißt das Feld Card Verification Value, Card Verification Code, Card Identification Number oder Card Security Code. In der technischen Dokumentation tauchen außerdem Bezeichnungen auf, die eine Position in den auf der Karte gespeicherten Daten beschreiben. Diese Unterscheidung ist inhaltlich bedeutsam: Die allgemeine Bezeichnung meint die codierten Daten im Magnetstreifen oder im Chip, während die mit einer Nummer versehene Bezeichnung die gedruckte Fassung meint, die der Kunde von der Karte abliest. Zwei völlig verschiedene Dinge, die im Sprachgebrauch oft zusammenfallen.
Warum hat der Code auf manchen Karten drei und auf anderen vier Stellen?
Die Länge ist eine Entscheidung des jeweiligen Netzwerks und hat mit Sicherheit nichts zu tun. Ein vierstelliger Code ist nicht schwerer zu erraten oder zu fälschen als ein dreistelliger; er ist lediglich länger. Wer annimmt, dass eine Karte mit vier Stellen besser geschützt ist, irrt.
Für Software ist die Länge dennoch ein praktisches Problem. Ein Formularfeld, das fest auf drei Zeichen begrenzt ist, schneidet jeden vierstelligen Code ab. Der Nutzer sieht keinen Fehler vor dem Absenden, die Zahlung wird abgelehnt, und die Fehlermeldung erscheint irgendwo in einem Protokoll ohne Bezug zur eigentlichen Ursache. Die korrekte Umsetzung ist, die Länge vom erkannten Netzwerk abhängig zu machen: drei Stellen im Regelfall, vier Stellen bei American Express.
Ein weiterer Punkt betrifft die Anzeige. Sobald ein Nutzer mehr als eine Karte hinterlegen kann, entsteht die Frage, welche Karte zu welchem Code gehört. Der Code auf der Rückseite ist nicht immer leicht zu finden, besonders bei Karten mit großen Logos oder Prägeelementen, und eine kurze Beschreibung in der Hilfe erspart viele Supportfälle. Die Frage, wann eine Karte überhaupt gültig ist, behandelt der Beitrag zum Ablaufdatum der Karte.
Was beweist der Code, und was nicht?
Der Code beweist eine einzige, eng umrissene Sache: Die eingebende Person hatte Zugang zur physischen Karte. Das ist im Fernabsatz wertvoll, weil Käufer und Verkäufer sich nicht sehen und die Karte nicht in einem Terminal gelesen wird.
Er beweist nicht, dass die Person die Karte rechtmäßig besitzt. Wer ein Foto der Karte hat, kennt den Code ebenfalls. Er beweist nicht, dass das Konto gedeckt ist, dass die Karte nicht gesperrt wurde und dass der Kauf legitim ist. Der Code ist ein Indiz, das die Betrugsquote senkt, und kein Gate, das Betrug ausschließt.
Die Abwesenheit des Codes ist umgekehrt ebenfalls kein Betrugsbeweis. Karten werden neu ausgestellt, Codes werden unleserlich, Kunden lesen die verkehrte Seite ab. Eine Ablehnung wegen eines fehlenden Codes ist ein Formfehler und sollte im Formular auch so behandelt werden, nicht als Sicherheitsvorfall.
Warum verbieten die Kartenregeln das Speichern des Codes?
Die internationalen Sicherheitsanforderungen für die Kartenindustrie ordnen den Sicherheitscode den sensiblen Authentifizierungsdaten zu. Für diese Kategorie gilt eine strenge Regel: Sie dürfen zur Autorisierung verwendet werden, aber nach der Autorisierung dürfen sie nicht mehr aufbewahrt werden. Nicht verschlüsselt, nicht gehasht, nicht in einer separaten Tabelle, nicht in einer Sicherungskopie.
Praktisch heißt das: Es gibt keine Spalte, in der der Code stehen darf, und keine Datei, in der er überleben darf. Der klassische Verstoß ist alltäglich und unauffällig. Eine Bestelltabelle bekommt für die Fehlersuche eine Spalte für den Code. Eine Protokollierung schreibt den vollständigen Anfrageinhalt mit, weil das beim Debuggen hilfreich war. Ein Fehlerbericht hängt die Formulardaten an. Eine Wiederholungswarteschlange behält die ursprüngliche Zahlungsanfrage samt Code. In jedem Fall liegt ein Datum mit direktem Missbrauchswert auf der Platte, das dort niemals sein dürfte.
Die Anforderungen an Testdaten vertiefen, was das für Testumgebungen bedeutet, und warum synthetische Werte dort die einzige saubere Lösung sind.
Ein Sicherheitscode-Feld fehlerfrei ausfüllen
So unscheinbar das Feld ist, so viele Fälle hat es. Wichtig ist, dass die Eingabe nie normalisiert wird wie eine Zahl, denn ein führender Wert kann bedeutsam sein. Weitere typische Fälle:
- Einfügen längerer Zeichenketten. Betroffene Formulare sollten das Einfügen erlauben, aber auf die zulässige Länge begrenzen statt abzuschneiden.
- Nichtnumerische Zeichen. Buchstaben gehören mit einer klaren Meldung zurückgewiesen.
- Leerzeichen am Rand. Wer den Code abliest und ein Leerzeichen mitkopiert, sollte nicht scheitern.
- Eingabehilfen des Browsers. Manche Hilfsmittel füllen das Feld nicht, weil die Kartenverwaltung es ausdrücklich ausschließt, und Nutzer suchen dann vergeblich nach der Autovervollständigung.
- Mobile Tastatur. Auf kleinen Geräten sind Zifferneingaben hilfreich, weil sie das Abtippen von der Karte deutlich erleichtern.
Ein letzter Fall wird regelmäßig falsch gelöst: die Maskierung. Wer die Eingabe ab der ersten Stelle verbirgt, nimmt dem Nutzer jede Möglichkeit, das Abtippen zu prüfen. Beim Sicherheitscode ist eine Maskierung ohnehin unnötig, da der Wert nirgends gespeichert wird.
Für Entwickler: den Code aus Logs und Speichern heraushalten
Die technische Aufgabe lautet nicht, den Code zu schützen, sondern ihn gar nicht erst zu behalten. Drei Maßnahmen decken fast alles ab.
Erstens: Das Zahlungsformular darf den Code nicht an den eigenen Server schicken. Die Felder werden von der Komponente des Dienstleisters gerendert oder per Tokenisierung erfasst, sodass der Wert direkt zu ihm fließt. Damit entfällt die Frage nach der Spalte.
Zweitens: Anfrageinhalte dürfen nicht pauschal protokolliert werden. Ein Filter, der bekannte sensible Felder vor dem Schreiben entfernt, ist die einzige verlässliche Variante, denn eine Ausnahmeliste wird früher oder später vergessen.
Drittens: Fehlerberichte und Warteschlangen zählen zum Speicherort. Ein abgefangener Aufruf, der die Formulardaten in eine Fehlerverfolgung schreibt, ist ein Speichervorgang im Sinne der Regel. Wer das nicht testet, entdeckt es erst bei einer Prüfung. Die Checkliste für Zahlungsformulare führt diese Punkte als eigene Prüfschritte.
Testkarten und ihre Platzhaltercodes
In Sandbox-Umgebungen tauchen Testkarten mit beliebigen Sicherheitscodes auf. Diese Werte sind reine Attrappen; der Sandbox-Anbieter prüft ihre Länge gegen das erkannte Netzwerk und wertet das Ergebnis als bestanden. Sie sind damit ideale Formulardaten und zugleich vollständig wertlos für einen echten Zahlungsvorgang.
Wer Testfälle zusammenstellt, sollte absichtlich einen drei- und einen vierstelligen Fall aufnehmen, damit der Längenunterschied zwischen Netzwerken tatsächlich ausgeübt wird, und zusätzlich einen Fall mit zu kurzer Eingabe für den Fehlerpfad. Der Kartennummern-Generator erzeugt passende Kombinationen aus Nummer, Ablaufdatum und Sicherheitscode, sodass ein vollständiges Formular befüllt werden kann, ohne Werte von Hand zusammenzusuchen.
Nächste Schritte
Behandeln Sie den Sicherheitscode als das, was er ist: ein kurzlebiger Beweis, der einmal geprüft und dann vergessen wird. Machen Sie die Feldlänge vom erkannten Netzwerk abhängig, lassen Sie keine Maskierung zu, die das Abtippen stört, und stellen Sie sicher, dass kein Protokoll, keine Warteschlange und kein Fehlerbericht den Wert aufbewahrt.