Ok, wenn dies eine Geschäftsanforderung ist, die Sie erfüllen müssen (überprüfen Sie, ob bereits eine Karte im System vorhanden ist), würde ich dies so tun.

Erstens ermöglicht PCI-DSS, dass eine PAN (die primäre Kontonummer oder Kreditkartennummer) in Hash-Form unter Verwendung von "starker Kryptographie" gespeichert wird, und sie empfehlen (erfordern jedoch nicht), dass a Salz auch verwendet werden. PCI-DSS v3 § 3.4 (PDF-Link) Der Grund besteht darin, die Fähigkeit einer böswilligen Partei, die den Hash erhält, daran zu hindern, die PAN zu bestimmen, die als Eingabe für den Hash verwendet wurde.

Zweitens ist Ihr Plan, dies in einem separaten, sicheren System zu speichern und nur über eine API verfügbar zu machen, eine gute Tiefenmaßnahme. Wenn ich dies implementieren würde, würde ich keinen Hash an das Primärsystem zurücksenden lassen. Ich würde einfach den Hash als Parameter für den API-Aufruf verwenden und die API "true" oder "false" zurückgeben lassen, je nachdem, ob der Hash ist bereits im System vorhanden oder nicht.

Für die Hashing-Funktion besteht der Schlüssel zum Verhindern der Wiederherstellung der Eingaben (wie von PCI-DSS gefordert) darin, einen Algorithmus auszuwählen, mit dem Sie den Prozess ausführen können rechenintensiv, daher ist die Aufgabe, den relativ kleinen Eingaberaum gültiger PANs brutal zu erzwingen, relativ langsam. SHA-512, vorgeschlagen durch eine andere Antwort, ist nicht dieser Algorithmus. Betrachtet man die von hashcat.net bereitgestellte Testmatrix für Hash-Cracking, so kann die schnellste Maschine in ihrer Matrix fast 2 Milliarden SHA-512-Hashes pro Sekunde berechnen. Bei einem geschätzten Eingabebereich von ungefähr 30.000.000.000.000 Karten ** bedeutet dies, dass Sie ungesalzen den SHA-512 jeder dieser PANs in etwas mehr als 4 Stunden berechnen und die Kartennummern für jede Karte in der Datenbank haben können, falls dies jemals der Fall sein sollte gestohlen werden.

Was wir also brauchen, ist eine langsame Hash-Funktion. Die Definition von langsam ändert sich jedoch ständig, wenn Computer schneller werden und sich die Technologie weiterentwickelt. Dies bedeutet, dass eine sichere Hash-Funktion eine Funktion mit einem einstellbaren Arbeitsfaktor ist, sodass Sie im Laufe der Zeit den Rechenaufwand erhöhen können, der zum Berechnen des Hash einer bestimmten Eingabe erforderlich ist. Es gibt mehrere Kandidatenalgorithmen, die diese Kriterien erfüllen, einschließlich PBKDF2, bcrypt und scrypt. Der allgemeine Konsens für Passwort-Hashing ist bcrypt, und das würde ich hier vorschlagen. Stellen Sie die Kosten so hoch ein, wie es Ihre Anwendung zulässt. Es ist wahrscheinlich nicht etwas, das Sie furchtbar häufig berechnen werden (ich würde mir vorstellen, dass Sie abhängig von Ihrer Anwendung x Hashes pro Minute oder Stunde oder Tag anstatt pro Sekunde betrachten werden) und höher Je höher die Kosten, desto schwieriger wird es für einen Gegner, der den Hash erfasst, brutale Gewalt anzuwenden.

** Meine Schätzung basiert auf einer 9-stelligen Kontonummer, einer berechenbaren Prüfziffer, die die Komplexität nicht erhöht, und einer WAG von 30.000 aktiven Bankidentifikationsnummern (die ersten 6 Ziffern der Karte) basierend auf eine Liste, die ich gefunden habe.

Ich kann nicht kommentieren, wie Stripe das macht, aber ich kann Ihnen genau sagen, wie Braintree das macht (weil ich dort arbeite). Wenn ich raten müsste, verwendet Stripe wahrscheinlich eine ähnliche Methode.

In der Braintree-API bieten wir eine eindeutige Nummernkennung für eine Kreditkarte an. Diese Kennung ist ein zufälliger undurchsichtiger Token, der für die in unserem System gespeicherte Kartennummer immer gleich ist. Der Startwert für diese Nummer ist je nach Händler in unserem System unterschiedlich, sodass Sie sie nicht zwischen Händlern vergleichen können.

Wenn eine neue Karte eingeht, prüfen wir sie, indem wir sie mit einer Spalte mit Hash + Salz vergleichen. Wenn es mit dieser vorhandenen Spalte übereinstimmt, wissen wir, dass wir dieselbe eindeutige Nummernkennung zurückgeben können. Wenn es keinem vorhandenen Datensatz entspricht, verwenden wir einen kryptografisch sicheren Pseudozufallszahlengenerator, um eine neue eindeutige Nummernkennung zu erstellen und sicherzustellen, dass sie nicht mit einer vorhandenen in Konflikt steht.

Auf diese Weise wird der Hash ausgeführt + Salted Value verlässt unser Backend nie, aber wir können einem Händler dennoch die Möglichkeit bieten, gespeicherte Kreditkarten eindeutig zu identifizieren.

Das Hashing von Kreditkartennummern ist kein Ersatz für die Sicherung der Daten. Wenn Ihr System nicht sicher genug ist, um unformatierte Kreditkartennummern zu speichern, ist es nicht sicher genug, um CC-Hashes zu speichern.

Dasselbe gilt für alles, was eine feste Größe und einen begrenzten Zeichensatz hat: Geburtsdatum, Telefonnummer , zip usw.

Kreditkarten sind alle sechzehn Ziffern und während 10 ^ 16 wie eine große Zahl erscheint, ist es für Rechenressourcen ziemlich einfach. Wenn ich Ihre Tabelle mit CC # -Hashes habe, kann ich diese leicht mit einer Regenbogentabelle angreifen und eine vollständige Liste der Kreditkarten erhalten. Das Salzen der Werte vor dem Hash macht die Suche unmöglich.

Alle möglichen CC-Werte: weniger als 10 ^ 16.

Stellen Sie sich zum Vergleich vor, Ihre Benutzer haben ein angemessenes 8-stelliges Passwort mit a verwendet 20-Byte-Salz: 62 ^ 28.

(Wenn ich Ihr PCI-Prüfer wäre, würde ich das Hashing von Kreditkarten als gleichbedeutend mit dem Speichern der Kartennummern selbst betrachten.)

Die Antwort wird Sie enttäuschen: Wenn ein Dienst / Orakel / Hash Ihnen sagen kann, ob eine Eingabenummer gespeichert ist, kann sie mit sehr wenig roher Gewalt gebrochen werden.

Bedenken Sie, dass in weiten Teilen des Landes Kreditkarten von relativ wenigen Banken in ihrer geografischen Region ausgestellt werden. Sie können die BIN-Nummern für die beliebtesten dieser Banken ganz einfach lernen. Angenommen, Sie haben eine Quittung aus einem Geschäft in Memphis und dort steht VISA **** 1234. Die Wahrscheinlichkeit liegt bei etwa 20%, dass es sich um eine von zehn verschiedenen BINs handelt, die zu den größten Banken in der Region Memphis gehören. Das sind 10 ^ 1 Vermutungen für die ersten sechs Ziffern. Als nächstes kennen Sie die letzten 4, weil sie auf der Quittung abgedruckt sind. Das sind jetzt nur 10 ^ 1 Vermutungen, die 10 der 16 Ziffern abdecken. Von den verbleibenden sechs Ziffern iterieren Sie über 5 und berechnen Sie die letzte mit Luhn. Das sind 10 ^ 6 Tests, die in 20% der Fälle eine gültige Kontonummer ergeben.

Alles, was Sie tun müssen, um eine Nummer zu testen, ist eine 100.000-malige Schleife durch den Dienst. Es spielt keine Rolle, ob der Dienst einen Hash oder eine Verschlüsselung oder einen Zauberstab verwendet, um die Kontonummern zu schützen, solange er Ihnen sagt, ob Ihre Eingabe übereinstimmt oder nicht.

Möglicherweise stellen Sie fest, dass dies nur in etwa 20% der Fälle funktioniert. Bedenken Sie, dass der Typ, der Target gestohlen hat, 40 Millionen Kontonummern genommen hat und nicht alle verkaufen konnte, da es nicht genug Gauner auf der Welt gab, um so viele zu kaufen. 20% davon sind 8 Millionen, und wahrscheinlich hat er auch nicht so viele verkauft. 20% sind also gut genug für einen Angreifer.

tl; dr:
Es ist nicht möglich, so etwas wirklich sicher zu machen, aber es kann "wahrscheinlich gut genug" gemacht werden, um brauchbar und akzeptabel zu sein

Bei Ihren Optionen handelt es sich im Grunde genommen um eine Form von verschlüsseltem Speicher (mit dem Risiko, dass Verschlüsselungsschlüssel gestohlen werden, da diese zur Entschlüsselung vorhanden sein müssen) oder um Hashing mit den bekannten Problemen des Hashing Passwörter (eine Kreditkartennummer ist im Grunde ein "Passwort").

Ich würde dies als zweistufiges System implementieren, bei dem die erste Ebene ein einfacher CRC32 und die zweite Ebene ein Vielfaches wäre iterierte sichere Hash-Funktion. Ja, CRC32 ist kein kryptografisch sicherer Hash, aber das spielt in diesem speziellen Fall keine Rolle, da der CRC nicht das schwache Glied ist.
Wenn der Gedanke, einen nicht kryptografisch zu verwenden, Ein sicherer Algorithmus macht Ihnen zu viel Angst. Sie können den CRC dennoch durch einen kryptografisch gesicherten Algorithmus ersetzen und nur z Die niedrigstwertigen 32 (oder 16, für einen größeren Rand) Bits aus dem resultierenden Hash.

Der Grund für diesen Ansatz ist, dass der Bereich möglicher Eingaben nur etwa 39 Bits ^{[1] . Es ist praktisch unmöglich, diesen Schlüsselraum auf wirklich sichere Weise zu hashen, während das System für die vorgesehene Verwendung betriebsbereit bleibt.
Ein Brute-Force-Angriff auf einen 39-Bit-Schlüsselraum ist nicht nur theoretisch machbar, sondern auch recht trivial - es sei denn Jede einzelne Operation ist extrem teuer.}

Die Hauptbedrohung, gegen die Sie sich verteidigen müssen, ist der Diebstahl Ihrer Datenbank, gefolgt vom brutalen Erzwingen, dass Ihre Hashes gültige Kartennummern abrufen. Das nächstbeste, was ein Angreifer tun könnte, wäre online abzufragen, ob eine unbekannte Nummer, die mit einer zufällig übermittelten Nummer identisch ist, zuvor verwendet wurde, oder ob eine bereits bekannte gültige Nummer wurde verwendet (keines ist jedoch sehr nützlich!).

Kreditkarten sind normalerweise 5 Jahre gültig. Damit das System sicher ist, muss es mindestens 5 Jahren Brute-Force standhalten. Mit anderen Worten, die für eine einzelne Überprüfung ausgeführte Arbeit muss so rechenintensiv sein, dass eine dedizierte Crackmaschine mit mehreren GPUs nicht mehr als 2 ^ 39 / (5 * 365 * 86400) = 3486,5 Überprüfungen pro Sekunde ausführen kann.

Unter Berücksichtigung der bekannten Zahl von 348 Milliarden pro Sekunde aus dem Jahr 2012 müsste der einzige wirklich sichere Ansatz den Wert von mindestens 100 Millionen Hashing speichern. Unter Berücksichtigung des Mooreschen Gesetzes wären das inzwischen 200 Millionen, und wir ziehen nicht einmal die Möglichkeit in Betracht, dass jemand zwei oder drei solcher Maschinen (oder vielleicht zehn) besitzt.

Dies ist jedoch still berücksichtigt nicht die Tatsache, dass Banken von Natur aus dumm sind und erhöht einfach die vorletzte Ziffer für eine neue gültige Nummer (und aktualisiert die Prüfziffer). Alle meine in den letzten 20 Jahren ausgestellten Kreditkarten hatten dieselbe Nummer, mit Ausnahme der vorletzten Ziffer, die 0, 1, 2, 3, ... erhöht.
Dies bedeutet, dass die Planung für 5 Jahre noch erfolgt ist nicht genug . Jemand, der eine abgelaufene Kreditkartennummer kennt, kann trivial die gültige Nummer der Follower-Karte ableiten. Sie müssen daher eher für so etwas wie 30 Jahre planen, nicht 5 Jahre. Ich überlasse die Extrapolation von Moores Gesetz auf weitere 20 bis 30 Jahre für Hausaufgaben.

Damit das System wirklich, wirklich sicher ist, müsste Ihr Server das ausführen Dies entspricht einer Billion Hashes (oder mehr) pro Überprüfung, die mit einer Rate von beispielsweise 10 Millionen pro Sekunde für eine typische CPU-Implementierung mehr als einen Tag in Anspruch nehmen würden. Mit anderen Worten, das System ist für den vorgesehenen Zweck vollständig unbrauchbar.

Es wird etwas benötigt, das mehrere Größenordnungen schneller ist. Die meisten Abfragen sind negative Abfragen, und ein einfacher, schneller Hash könnte verwendet werden, um 99,9% aller Negative zu entfernen, wenn dies die ohnehin schwache Sicherheit nicht noch schwächer macht. Hier kommt CRC32 ins Spiel.

Wenn die CRC32 von zwei Kreditkartennummern nicht übereinstimmen, ist garantiert, dass die Nummern nicht identisch sind. Meistens ist dies der Fall und Sie können sofort "Nein!" Zurückgeben. Sie können 99,9% der Arbeit überspringen, ohne etwas preiszugeben.
Wenn die CRCs übereinstimmen übereinstimmen, ist dies möglicherweise ein Treffer, es besteht jedoch die Möglichkeit einer Hash-Kollision. Nun wird der sichere kryptografische Hash (der mindestens 160, besser 256 Bit haben würde) berechnet und verglichen. Die Wahrscheinlichkeit einer Kollision ist jetzt vernachlässigbar. Wenn der Hash übereinstimmt, ist es sicher, dass die Anzahl übereinstimmt.

CRC32 enthält 32 Informationsbits. Es ist unmöglich , 39 Bit Informationen aus 32 Bit wiederherzustellen, unabhängig davon, welche Rechenressourcen Sie besitzen. Daher ist die Verwendung des CRC in diesem Fall sicher (oder zumindest nicht weniger sicher als alles andere).

Wie von Ben Voigt hervorgehoben, handelt es sich um Natürlich ist es immer noch möglich, die Informationen zu erraten, die nicht wiederhergestellt werden können, und 7 zu erratende Bits sind keine schreckliche Menge (durch Verketten des Ablaufdatums werden diese 15 Bits erreicht). Das stimmt, aber Sie können nicht viel dagegen tun.

Was ist überhaupt mit CRC und Sicherheit? CRC ist nicht kryptografisch sicher. Es ist relativ einfach, Bits zu manipulieren, um eine gewünschte Ausgabe zu erhalten (hier kein Problem, wäre dies bei Anmeldungen), und die Funktion kann trivial umgekehrt werden (4 Tabellensuchen plus ein paar Verschiebungen und xor) auf eine 32-Bit-Eingabe. ein etwas größeres Problem. Zum Glück, aber dieses Bitmuster ist ziemlich wertlos, da es weder eine gültige Zahl noch eine Teilmenge eines 39-Bit-Musters ist, das eine gültige Zahl sein könnte (außer durch Zufall).

Das brutale Erzwingen des gesamten 39-Bit-Schlüsselraums ist einfacher als der Versuch, Streiche auf dem CRC zu spielen, da dies leider einfach und schnell ist: Eine SSE4.2-Implementierung benötigt ungefähr einen halben Zyklus pro Byte (also) 2 Zyklen pro Hash), was bedeutet, dass ein Desktop-Computer den gesamten Schlüsselbereich in ein oder zwei Sekunden ausführen kann (vorausgesetzt, die Schlüssel werden mit allen in L1 passenden verglichen).

Die umfassende Suche würde alle 39-Bit-Daten anzeigen Muster mit demselben CRC, was bedeutet, dass es sich möglicherweise um Kreditkartennummern handeln kann. Mit dem Luhn-Algorithmus kann der Angreifer sofort 9 von 10 nicht gültigen Nummern verwerfen. Das ist zwar schlecht, aber es ist wirklich nur eine Folge davon, dass nicht zu viele Eingabemöglichkeiten vorhanden sind und eine Prüfziffer oben implantiert ist!

Trotzdem ist der CRC tatsächlich stärker Dieses Szenario ist ein kryptografisch sicherer Algorithmus: Angesichts der weltweit im Umlauf befindlichen 2-3 Milliarden Kreditkarten liegt die Wahrscheinlichkeit einer Kollision mit einem 160-Bit-Hash zwischen 1 und 10 ^{20 sup> und nicht einmal Denken Sie über die Chancen nach, einen 256-Bit-Hash zu verwenden. Dies bedeutet, dass jeder Treffer während Ihrer umfassenden Suche im 39-Bit-Schlüsselbereich sofort Ihnen die einzig garantierte gültige Kartennummer gibt. Ein Treffer auf dem CRC32 gibt Ihnen nur eine von vielen möglichen Zahlen.}

Eine Sache, die Sie tun könnten, um Geschwindigkeit gegen Sicherheit einzutauschen, wäre, einige Informationen weiter von der zu entfernen CRC Zum Beispiel könnten Sie einfach die höchstwertigen 8 oder 16 Bits des CRC verwerfen, wodurch diese zu den Bits hinzugefügt werden, die ein Angreifer erraten muss. Dies wird natürlich die Wirksamkeit des Schnittes etwas verringern, aber nicht zu drastisch. Anstatt 99,99% der Arbeit zu beschneiden, könnten Sie am Ende 99% oder 98% beschneiden, was immer noch sehr gut ist.

Die zweite Verifizierungsebene muss, wie oben angegeben, ein kryptografisch sicherer Hash sein, der mindestens eine Million Iterationen ausführt, ähnlich wie bei einem Schlüssel-Stretching-Schema (tatsächlich benötigt er viel mehr als das , aber das System muss auch praktisch verwendbar bleiben.
Der Implementierer muss hier das Risiko gegen die Verwendbarkeit austauschen. Ein Server sollte mindestens noch in der Lage sein, ein paar Dutzend Anforderungen pro zu verarbeiten zweite. Kunden / Händler stimmen nicht zu, wenn das Nachschlagen einer Nummer mehrere Minuten (oder länger) dauert, unabhängig von den Auswirkungen auf die Sicherheit. Es ist auch nicht praktisch, mehr oder weniger einen dedizierten Server pro Händler zu haben.

Da das Abgleichen nur auf Händlerbasis interessant ist, könnte man ein Salz pro Händler konstant verwenden und Kartennummern redundant speichern zusammen mit einem Index der Händler-ID, der in den Zuständigkeitsbereich eines vernünftigen Datenbanksystems fallen sollte.

Ich würde empfehlen, das Ablaufdatum mit der Nummer zu verketten, da dies die Situation etwas weniger miserabel macht. Meine Kreditkarten sind immer 5 Jahre gültig (ich bin mir nicht sicher, ob dies die universelle Regel ist, aber ich würde es annehmen). Wenn Sie also das Ablaufdatum hinzufügen, werden 5 * 12 Möglichkeiten oder 5,9 Bit hinzugefügt (diese sind so gut wie kostenlos). da brauchst du die Ablaufdaten sowieso in einer Transaktion!).

Ergänzen Sie die vorherigen Vorschläge. Wie wäre es mit SHA-3 (das anscheinend erst 2015 offiziell war, später als diese Diskussion), bei dem der Kartennummer ein händlerspezifischer geheimer Schlüssel vorangestellt wird, um die Hashes händlerspezifisch zu machen.

Das einfache Voranstellen eines geheimen Schlüssels an die Nachricht war für SHA-1 und SHA-2 aufgrund ihrer Schwäche bei der Längenerweiterung unsicher. Dies ist bei SHA-3 nicht der Fall, das von Natur aus gegen Längenverlängerungsangriffe resistent ist. Wie hier erklärt, könnte man SHA-3 sogar für die MAC-Berechnung verwenden, indem man der Nachricht einfach den Schlüssel voranstellt.

Natürlich bleibt das Problem, wie die geheimen Schlüssel sicher gespeichert werden . Ich habe keine Erfahrung mit der Zahlungskartenbranche. Ich bin gerade auf diese Frage gestoßen und fand sie interessant. Ich würde gerne einige Kommentare von erfahreneren Benutzern zu den Problemen erhalten, die mit dem Umgang mit Kartennummern (und ihrem relativ kleinen Suchraum) bei Verwendung dieses Ansatzes zu tun haben.

Sie dürfen es nicht gemäß den hier definierten PA-DSS-Standards speichern: https://www.pcisecuritystandards.org/documents/pa-dss_v2.pdf

Darin heißt es :

1.1 Speichern Sie keine vertraulichen Authentifizierungsdaten nach der Autorisierung (auch wenn diese verschlüsselt sind): Zu den vertraulichen Authentifizierungsdaten gehören die Daten, die in den folgenden Anforderungen 1.1.1 bis 1.1.3 aufgeführt sind.

In der nebenstehenden Spalte heißt es:

Wenn diese Zahlungsanwendung vertrauliche Authentifizierungsdaten speichert, stellen Sie sicher, dass die Anwendung nur für Emittenten und / oder Unternehmen bestimmt ist, die die Ausgabe von Diensten unterstützen

Ich gehe davon aus, dass Sie kein Emittent oder Unternehmen sind, das die Ausgabe von Diensten unterstützt. Beachten Sie, dass die Target Corporation kürzlich gehackt wurde und Kreditkarteninformationen in Echtzeit und von Servern gestohlen wurden, die die Daten nicht durchgehend verschlüsselt haben. Nach meinem Verständnis wird es korrigiert und sicherer gemacht. Ehrlich gesagt, speichern Sie es nicht Zeitraum. Selbst wenn Sie SHA512-Hash verwenden, ist Ihre Implementierung möglicherweise fehlerhaft. Mit den besten Gegenmaßnahmen möchte ich nicht am Ende einer Klage stehen.

Bearbeiten:

Technisch ist dies in Abschnitt 2.3 von PA-DSS v2.0 zulässig. Aber tu es nicht.

Wenn Sie es tun wollen, fügen Sie eine Art Verschleierung hinzu. Ich habe mir nur Downvotes garantiert, aber die Verschleierung ist nicht wertlos, wie manche behaupten werden.

Wenn Sie davon ausgehen, dass das System bekannt ist, gibt es keinen Wert. Aber wenn das System nicht bekannt ist, gibt es absolut Wert. Eine IV, die verwendet wird, um zu "pfeffern", wie Xander es ausdrückte, wäre eine Form der Verschleierung, ohne die Kollisionen zu erhöhen und die Fähigkeit zur Abfrage aufrechtzuerhalten.

Ein Pfeffer wäre jedoch keine sehr effektive Verschleierung , es sei denn, der Pfeffer ist groß genug, um nicht in angemessener Zeit erraten zu werden. 100 zufällige Bytes könnten übertrieben sein, aber es gibt keinen Grund, nicht groß zu werden.

Eine andere Sache, die eine effektive Verschleierung sein könnte, wäre, nicht anzunehmen, dass sowohl der Pfeffer als auch die Nachricht gleichzeitig erreicht werden Wenn Sie die Hashes in einer nächtlichen Charge regelmäßig aufwärmen (wobei Sie nachverfolgen, wie viele Runden Sie haben), benötigen Sie eine weitere Information - wie viele Runden oder wie die Runden berechnet werden.

Denken Sie daran dass ich das nicht für eine gute idee halte, denke ich hier nur laut nach. Wenn Ihre Umgebung für Kreditkarten sicher genug ist, würde ich sie nicht nur nicht hashen, sondern sie auch in einer Tabelle speichern, die für die schnellste Suchleistung ausgelegt ist.