Hashing von Daten mit geringer Entropie & Kreditkarten in APAC

Hier ist eine unbequeme Tatsache: Hashing ist nicht dasselbe wie Schutz. Sie können einen SHA-256-Hash einer Kreditkartennummer speichern, vollständig PCI-DSS-konform sein und trotzdem effektiv keinen Schutz haben, weil der Wert, den Sie gehasht haben, schlicht nicht genug Entropie enthält, um Brute Force zu widerstehen.

Das stolpert selbst sorgfältige Engineering-Teams, weil sich Hashing sicher anfühlt. Der Hash ist einwegig, das Original lässt sich nicht durch Umkehrung der Funktion wiederherstellen, also sind die Daten doch geschützt. Der Fehler liegt nicht im Hash. Der Fehler liegt in dem, was Sie hineingefüttert haben.

Das Entropieproblem, in echten Zahlen #

Eine 16-stellige Kartennummer ist nicht zufällig. Ihre Struktur ist öffentlich und fest:

• Die ersten 4 bis 6 Ziffern sind die Issuer Identification Number (IIN): das Bankpräfix, vollständig öffentlich.
• Die letzte Ziffer ist eine Prüfsumme, berechnet nach dem Luhn-Algorithmus, einer 1954 veröffentlichten Formel. Sie ist kein Geheimnis; sie dient der Fehlererkennung.

Maskieren Sie nun die PAN so, wie PCI DSS es üblicherweise erlaubt: erste 4 bis 6 Ziffern und letzte 4 sichtbar, die mittleren 6 bis 8 verborgen:

4532 AAXX XXXX 1234

Sind nur 4 Ziffern der IIN bekannt, bleiben 8 Ziffern unbekannt, höchstens also 100.000.000 mögliche Werte. Wendet man die Luhn-Prüfsumme an, überlebt nur 1 von 10 davon. Ihr tatsächlicher Suchraum sind 10 Millionen Werte. Das ist kein Passwort. Das ist eine sehr kleine Liste.

Wie schnell lassen sich 10 Millionen Hashes testen? #

Hier wird es schlimmer. SHA-256 ist von Design her schnell. Er ist für Integritätsprüfung mit Gigabit-Geschwindigkeit gebaut, nicht zur Speicherung von Geheimnissen. Moderne GPU-Cracking-Benchmarks sind öffentlich und reproduzierbar:

Zehn Millionen Versuche geteilt durch 8,5 Milliarden pro Sekunde ergeben rund ein Tausendstel Sekunde. Auf einer einzigen Consumer-GPU. Selbst ein einzelner GPU-Rechner kann per Rainbow Table eine Kreditkartennummer „dehashen“, schneller als ein Blinzeln.

Die Schlussfolgerung ist unmissverständlich: konform ist nicht sicher. Bei Feldern mit geringer Entropie ist selbst SHA-2 (oder SHA-3) nicht sicher, selbst wenn es konform ist. Die Funktion ist einwegig; sie ist nur trivial erschöpfbar, wenn der Eingaberaum winzig ist. SHA-256 gegen SHA-512 oder SHA-3 zu tauschen behebt das nicht, denn sie sind gleich schnell.

Was „konform“ wirklich erlaubt #

PCI DSS sagt Ihnen eigentlich nicht, PANs mit SHA-256 zu hashen. Anforderung 3.5 verlangt, dass Sie die PAN mit starker Kryptografie unlesbar machen, was keyed Hashes und Verschlüsselung ausdrücklich nennt, und anmerkt, dass ein gehashter und gesalzener Index akzeptabel ist, wenn das Salt geheim ist und der Hash praktisch nicht umkehrbar. Das Problem: Ein nackter, ungesalzener SHA-256 über einen Raum von 10 Millionen Werten ist praktisch durch Erschöpfung umkehrbar und verfehlt damit den Sinn der Anforderung, auch wenn der Prüfhaken gesetzt wird.

Maskierung (Anzeige der ersten 4-6 und/oder letzten 4) ist eine separate Kontrolle: Sie schützt, was ein Bediener sieht, nicht was Sie speichern. Beide werden leicht verwechselt, und genau diese Verwechslung bringt maskierte, aber nackt gehashte PANs in Produktion.

So schützen Sie diese Daten richtig #

Die Lösung ist, Feldern mit geringer Entropie denselben Respekt zu zollen wie einem Passwort, denn mathematisch sind sie genauso schwach. Die Optionen, nach Präferenz sortiert:

1. Gar nicht speichern. Tokenisieren Sie die PAN und halten Sie die echte Nummer in einem separaten Vault oder HSM. Speichern Sie den Wert nie, gibt es nichts zu knacken.
2. Keyed Hashing (HMAC) mit geheimem Pepper. Müssen Sie nach PAN indexieren, nutzen Sie einen HMAC mit einem hochentropischen Schlüssel außerhalb der Datenbank. Ohne den Schlüssel ist Brute Force rechnerisch unfeasibel, ganz gleich wie gering die Eingabeentropie ist.
3. Speicherhartes Passwort-Hashing. Wo Sie den Wert allein mit dem Wert schützen müssen, verwenden Sie Argon2id (RFC 9106) oder scrypt mit individuellem Zufalls-Salt und so abgestimmten Parametern, dass jeder Versuch echte Zeit und echten Speicher kostet. Argon2id mit etwa 64 MB Speicherkosten verwandelt die exhaustive Suche von 0,001 Sekunden in Monate GPU-Zeit.
4. Salts und Peppers überall. Ein Zufalls-Salt pro Wert besiegt vorberechnete Rainbow Tables; ein geheimer Pepper besiegt Offline-Angriffe vollständig, solange er geheim bleibt.

Das OWASP Password Storage Cheat Sheet und NIST SP 800-63B empfehlen beide speicherharte Funktionen für Geheimnisse mit geringer Entropie, aus genau diesem Grund.

Die Lehre jenseits von Karten #

Das gilt für jeden Identifikator mit festem Format und begrenzter Entropie: Personalausweisnummern, Telefonnummern, Geburtsdaten und sogar schlecht generierte API-Keys. Ist der Eingaberaum klein, ist die Geschwindigkeit der Hash-Funktion Ihr Feind, und „konform“ ist kein Synonym für „sicher“.

Unser API & Application Security Review prüft, wie Ihr Code sensible Werte tatsächlich speichert und überträgt, und wir sagen Ihnen klar, wo ein abgehakter Prüfpunkt echte Daten exponiert.