Am 1. April 2022 werden die Karten­or­ga­ni­sa­tionen Visa und Mastercard die BIN (Bank Identi­fi­cation Number) ihrer Karten weltweit von 6 auf 8 Stellen ausdehnen. Von einer 16-stelligen Kredit­kar­ten­nummer (Primary Account Number, PAN) dienen dann in Zukunft die ersten 8 Stellen zur Identi­fi­kation des Karten­her­aus­gebers. Die BIN wird an vielen Stellen genutzt, wo die Verwendung der vollstän­digen PAN nicht nötig ist – z.B. für das Routing von Trans­ak­tionen oder für Reportings.

BINs und PCI DSS 

Überall dort, wo eine vollständige PAN genutzt wird, müssen die Systeme, Umgebungen, Prozesse und Personen die Anfor­de­rungen des Daten­si­cher­heits­stan­dards PCI DSS (Payment Card Industry Data Security Standard) erfüllen. So sinnvoll der Schutz der PAN durch den PCI DSS ist – für die BIN ist er nicht notwendig.

Im PCI DSS ist daher beschrieben, unter welchen Bedin­gungen für Teile der PAN nicht der gleiche Schutz wie für die volle PAN notwendig ist. Wird nicht die volle PAN gespei­chert, verar­beitet oder übertragen, sondern nur einige Stellen davon, spricht man im PCI DSS von „Trunkierung“. Ist zwar die volle PAN im Hinter­grund gespei­chert, aber in einer Appli­kation werden nicht alle Stellen angezeigt, spricht man im PCI DSS bei der Anzeige von „Maskierung“. Im Alltag wird für beide unter­schied­lichen Maßnahmen auch der Begriff „ausgeixt“ verwendet; aus Sicht des PCI DSS muss man diese aber unterscheiden.

Für Trunkierung und Maskierung galten bisher folgende Regeln:

• Maskierung: PCI DSS-Anfor­derung 3.3 besagt, dass maximal die ersten sechs und letzten vier Stellen („first 6, last 4“) der PAN angezeigt werden dürfen, solange es keinen Business Need für die Einsicht in die volle PAN gibt.
• Trunkierung: In PCI DSS-Anfor­derung 3.4 wird Trunkierung als Beispiel für die Unkennt­lich­ma­chung von PANs benannt, aber nicht genauer definiert. Die erlaubten Formate werden jeweils von den inter­na­tio­nalen Zahlkarten-Organi­sa­tionen festgelegt und vom PCI SSC im FAQ-Eintrag #1091 zusam­men­ge­fasst. Die meisten Zahlkarten-Organi­sa­tionen hatten sich dabei auf die Regel „first 6, any other 4“ geeinigt, die viele Jahre Bestand hatte.

Änderung der Regeln für Trunkierung und Maskierung 

Aufgrund der Umstellung auf 8‑stellige BINs und der Notwen­digkeit vieler Unter­nehmen, diese zu verar­beiten, haben die Zahlkarten-Organi­sa­tionen ihre Vorgaben nun aber geändert. In der aktuellen Zusam­men­fassung im FAQ-Eintrag des PCI SSC ist nun definiert, dass für 16-stellige PANs bei der Trunkierung „first 8, any other 4“ zulässig ist.
Die (Test)Kartennummer 4012888888881881 dürfte dann in Zukunft z.B. in der Form 40128888xxxx1881 gespei­chert und verar­beitet werden – es reicht aus, wenn beliebige vier Stellen hinter der BIN ausgeixt sind.
Lediglich für kürzere PANs bleibt es bei den bestehenden Regeln „first 6, any other 4“ (Discover) bzw. „first 6, last 4“ (American Express).  Bei der Maskierung wird eine entspre­chende Anpassung der PCI DSS-Anfor­derung mit der Umstellung auf PCI DSS v4.0 erwartet.

Aus Sicher­heits­sicht ist das Ausixen so weniger Stellen keine Verbes­serung – aus der Business-Perspektive ist die Änderung aber wohl notwendig. Es bleibt zu hoffen, dass dies in der Gesamt­sicht durch andere Sicher­heits­maß­nahmen ausge­glichen wird.
Auf jeden Fall stehen in Zukunft die Anfor­de­rungen des PCI DSS der Verwendung einer 8‑stelligen BIN nicht im Wege.

Vorsicht bei der Kombi­nation verschie­dener Formate 

Händler und Dienst­leister, die mit trunkierten Karten­daten arbeiten, sollten – unabhängig von der Länge der BIN – darauf achten, den Schutz der Karten­daten nicht durch die Vermi­schung verschie­dener Formate zu schwächen.

• Es muss darauf geachtet werden, dass die erwei­terten Trunkie­rungs­formate nur für 16-stellige PANs gelten. Die Länge der PAN muss also für die Trunkierung bei der Speicherung berück­sichtigt werden.
• Trunkie­rungs­formate wie „first 6, any other 4“ erlauben theore­tisch das Vorliegen unter­schied­licher trunkierter Versionen der gleichen PAN. Die oben angeführte Karten­nummer könnte in einem System als 40128888xxxx1881 gespei­chert sein, in einem anderen als 401288888888xxxx. Das ist nicht verboten – es muss jedoch darauf geachtet werden, dass keiner ohne entspre­chenden Business Need die beiden Versionen zusam­men­führen kann und somit weitere Stellen der PAN – bis hin zur vollstän­digen Karten­nummer – rekon­stru­ieren kann.
  Dies gilt genauso, wenn für Maskierung und Trunkierung unter­schied­liche Formate verwendet werden.
• Werden in einer Umgebung sowohl trunkierte PANs als auch die Hash-Werte von PANs gespei­chert, so sind die beiden Werte an sich erst einmal unkri­tisch. Lassen sich die trunkierten PANs und ihre Hash-Werte jedoch in Verbindung bringen, lässt sich über Rainbow Tables leicht die ursprüng­liche volle PAN rekon­stru­ieren. Auch in diesem Fall muss also über zusätz­liche Maßnahmen die Möglichkeit der Zusam­men­führung der beiden Versionen verhindert werden.