it-swarm.com.de

Hashing einer Kreditkartennummer zur Verwendung als Fingerabdruck

Transforming the credit card number into a fingerprint

Was ist der beste Weg, um eine Kreditkartennummer zu hashen, damit sie für Fingerabdrücke verwendet werden kann (d. H. Wenn Sie durch Vergleichen von zwei Hashes wissen, ob die Kartennummern übereinstimmen oder nicht)?

Idealerweise suche ich nach Empfehlungen, welches Hash + Salz für diesen Anwendungsfall gut geeignet sein könnte. Der Hash würde eine bestimmte Kartennummer eindeutig identifizieren. Mit diesem Attribut können Sie beispielsweise überprüfen, ob zwei Kunden, die sich bei Ihnen angemeldet haben, dieselbe Kartennummer verwenden. (da Sie im Klartext keinen Zugriff auf die Kartennummern hätten)

Fingerprints match

Um diesem Kontext einen gewissen Kontext zu geben, lesen Sie die Stripe API-Dokumente und suchen Sie nach fingerprint. Hier habe ich zum ersten Mal von diesem Konzept gehört. Die Kreditkarteninformationen werden auf einem sicheren Computer (irgendwo im Stripe-Backend) gespeichert, auf den der Kunde nicht zugreifen kann, und die API gibt den Fingerabdruck zurück, damit der API-Verbraucher Vergleiche anstellen kann (z. B. um Fragen wie = zu beantworten Wurde diese Karte schon einmal benutzt ?).

Lassen Sie uns dies klarstellen, denn ich weiß, dass Sie fragen werden: Ich versuche nicht, es zu replizieren. Ich bin nur neugierig zu verstehen, wie dies implementiert werden könnte

43
FloatingRock

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

In der Braintree-API bieten wir ein 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, sehen wir sie nach, 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 verlässt der Wert für Hash + Salted nie unser Backend, aber wir können einem Händler dennoch die Möglichkeit bieten, gespeicherte Kreditkarten eindeutig zu identifizieren.

28
John Downey

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

Erstens erlaubt PCI-DSS, dass ein PAN (die primäre Kontonummer oder Kreditkartennummer) in Hash-Form unter Verwendung von "starker Kryptographie" gespeichert wird, und sie empfehlen (aber nicht erforderlich) dass auch ein Salz verwendet wird. PCI-DSS v3 § 3.4 (PDF-Link) Der Grund ist, die Fähigkeit einer böswilligen Partei, die den Hash in den Griff bekommt, daran zu hindern, das PAN, das 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 es keinen Hash an das Primärsystem zurücksenden. 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 zu wählen, mit dem Sie den Prozess rechenintensiv gestalten können, sodass der relativ kleine Eingaberaum von Brute-Forcing erzwungen werden muss gültige PANs ziemlich langsam. SHA-512, vorgeschlagen von einer anderen 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 Scheckziffer, die die Komplexität nicht erhöht, und einer WAG von 30.000 aktiven Bankidentifikationsnummern (die ersten 6 Ziffern der Karte) basierend auf einer Liste, die ich gefunden habe.

31
Xander

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.

Gleiches gilt für alles, was eine feste Größe und einen begrenzten Zeichensatz hat: Geburtsdatum, Telefonnummer, Postleitzahl 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 Rainbow-Tabelle angreifen und eine vollständige Liste der Kreditkarten erhalten. Das Salzen der Werte vor dem Hash macht das Suchen unmöglich.

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

Stellen Sie sich zum Vergleich vor, Ihre Benutzer haben ein angemessenes 8-stelliges Passwort mit einem 20-Byte-Salt verwendet: 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.)

16
u2702

Die Antwort wird Sie enttäuschen: Wenn ein Dienst/Oracle/Hash Ihnen sagen kann, ob eine Eingabenummer in der Datei vorhanden ist, kann sie durch sehr wenig rohe Gewalt beschädigt 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.

9
John Deters

Ergänzung der bisherigen Vorschläge. Wie wäre es mit SHA das offenbar erst 2015 offiziell war, später als diese Diskussion), bei dem der Kartennummer ein händlerspezifischer Geheimschlüssel vorangestellt wird, um die Hashes händlerspezifisch zu machen.

Das einfache Voranstellen eines geheimen Schlüssels für 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 erklärt --- (hier , 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 der sicheren Aufbewahrung der geheimen Schlüssel bestehen. 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.

1
KurtWegner

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

Es sagt aus:

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 Dienstleistungen 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:

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

0
Brian

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 wurde, 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 wären vielleicht übertrieben, aber es gibt keinen Grund, nicht groß zu werden.

Eine andere Sache, die eine effektive Verschleierung sein könnte, wäre, nicht davon auszugehen, dass sowohl der Pfeffer als auch die Nachricht gleichzeitig erreicht werden. Wenn Sie also die Hashes in einer nächtlichen Charge regelmäßig aufwärmen (wobei Sie die Anzahl der Runden verfolgen), würden sie dies tun 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, ich denke 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.

0
Andrew Hoffman