Gibt es einen besten .NET-Algorithmus für die Kreditkartenverschlüsselung?

Question

Der Namespace .NET System.Security.Cryptography hat eine ziemlich verwirrende Sammlung von Algorithmen, die ich für die Verschlüsselung von Kreditkartendaten verwenden könnte. Welches ist das Beste?

Es muss eindeutig für einen relativ kurzen String sicher sein.

EDIT: Ich bin in Großbritannien, wo ich verstehe, dass wir OK sind, verschlüsselte Kreditkartendaten speichern, solange die dreistellige CVV-Nummer nie gespeichert wird. Und danke allen für die tollen Antworten.

Answer 1

Nichts für ungut, aber die Frage ist ein wenig "fehlgeleitet". Es gibt keine "Silberkugel" -Lösung. Ich würde empfehlen, Kryptographie im Allgemeinen zu lesen und dann eine Bedrohungsmodellierung durchzuführen. Einige Fragen (keineswegs eine umfassende Liste) sollten Sie sich fragen:

• Ist das Modul die Verschlüsselung das eine zu tun, die es entschlüsseln, muss (in diesem Fall den Einsatz symmetrischen Krypto) oder wird es Daten an einen anderen senden Modul (auf einer anderen Maschine), die es verwenden wird (in diesem Fall sollten Sie Public-Key-Krypto berücksichtigen)
• Was möchten Sie vor schützen? Jemand, der auf die Datenbank zugreift, aber nicht den Quellcode hat (in diesem Fall können Sie den Verschlüsselungsschlüssel direkt in die Quelle codieren)? Jemand schnüffelt an Ihrem lokalen Netzwerk (Sie sollten transparente Lösungen wie IPSec in Erwägung ziehen)? Jemand stiehlt Ihren Server (das kann sogar in Rechenzentren passieren - in diesem Fall sollte die vollständige Festplattenverschlüsselung in Betracht gezogen werden)?
• Müssen Sie wirklich die Daten behalten? Können Sie es nicht direkt an den Kreditkartenprozessor weiterleiten und löschen, nachdem Sie die Bestätigung erhalten haben? Können Sie es nicht lokal auf dem Client in einem Cookie oder Flash LSO speichern? Wenn Sie es auf dem Client speichern, stellen Sie sicher, dass Sie es serverseitig verschlüsseln, bevor Sie es in einen Cookie setzen. Wenn Sie Cookies verwenden, stellen Sie außerdem sicher, dass Sie nur HTTP angeben.
• Ist es genug, um die Gleichheit der Daten zu vergleichen (dh die Daten, die der Kunde mir gegeben hat, sind die gleichen Daten, die ich habe)? Wenn ja, erwäge, einen Hash davon zu speichern. Da Kreditkartennummern relativ kurz sind und einen reduzierten Satz von Symbolen verwenden, sollte für jedes vor dem Hashing ein eindeutiges Salz erzeugt werden.

Später bearbeiten: beachten Sie, dass Standard-Verschlüsselungsalgorithmen aus der gleichen Kategorie (zB 3DES und AES - beide symmetrisch Block Chiffren) von vergleichbarer Stärke. Die meisten (kommerziellen) Systeme sind nicht kaputt, weil jemand ihre Verschlüsselung brutal erzwang, aber weil ihre Bedrohungsmodellierung nicht detailliert genug war (oder ganz offen, sie hatten keine). Zum Beispiel können Sie alle Daten verschlüsseln, aber wenn Sie eine öffentlich zugängliche Webschnittstelle haben, die anfällig für SQL-Injection ist, wird es Ihnen nicht viel helfen.

Answer 2

3des ist ziemlich gut, speichern Sie das Salz neben, und halten Sie einen Standardschlüssel irgendwo nicht in der Datenbank oder einer Konfigurationsdatei. Auf diese Weise können sie nicht entschlüsselt werden.

Answer 3

Gemäß den PCI DSS Compliance-Regeln ist jeder branchenführende Verschlüsselungsstandard ausreichend. Also ein 3DES mit einem 256 Bit Schlüssel ist gut genug (obwohl andere Standards verwendet werden können). Überprüfen Sie das http://pcianswers.com/2006/08/09/methods-of-encrypting-data/

Answer 4

Es spielt keine Rolle.

Vollständige Kartennummern sollten niemals die Festplatte berühren.

Alles, was zählt, ist der Auth-Code.

Für Traces usw. werden nur die letzten 4 Ziffern xxxx xxxx xxxx 1234 und das Verfallsdatum verwendet.

Wenn Sie Kartennummern speichern, wird die Kryptografie von der erwerbenden Bank beauftragt.

Sofern Sie nicht der Erwerber sind, welchen Fall sollte es einen alten Unix-Programmierer/db2-Typ geben, den Sie fragen sollten.

„Kannst du es nicht lokal speichern auf dem Client in einem Cookie“ < - NIE

Answer 5

Es gibt auch die rechtlichen Aspekte zu berücksichtigen. Ich kenne die Situation nicht woanders, aber in Deutschland darf man einfach keine Kreditkartennummern speichern ¹⁾. Zeitraum. Es spielt keine Rolle, ob Sie sie verschlüsseln oder nicht und in welchem ​​Format Sie sie speichern.

Alle Sie können tun (und hier verweise ich aus dem Speicher, ohne jegliche juristische Kenntnisse) ist ein starker Hash (SHA-256?) Der Kreditkartennummer, zusammen mit den letzten vier Ziffern und der Accountnummer. Und ja, es ist trivial, die vollständige Zahl aus diesen Informationen allein wieder aufzubauen. Gesetze sind nicht immer logisch.

---

¹⁾ Außer wenn Sie ein staatlich zertifizierten Kreditkarteninstitut sind.

Answer 6

Hinweis: Sie sollten untersuchen, ob es legal ist, Kreditkartennummern zu speichern. In Schweden zum Beispiel müssen Sie von PCI (Payment Card Industry) zertifiziert werden, wo Ihre interne und externe Sicherheit getestet wird (lange mit vielen anderen Dingen).

Sie sollten sowohl ein- als auch zweimal nachdenken, bevor Sie die Kreditkarteninformationen speichern, da die Kosten für die Durchführung falscher Daten teuer sein können.

Answer 7

ich zu der Ansicht hinzufügen würde, dass Sie einfach nur sollten sie nicht speichern, wenn Sie einen wirklich, wirklich guten Grund haben, und sie in einem Cookie gespeichert ist eine wirklich schlechte Idee - sie sind nur too easy zu (Was passiert, wenn jemand einen Keks stiehlt - dann ist es egal, wie verschlüsselt er ist).

Wenn Sie wiederkehrende Zahlungen ausführen müssen, bieten die meisten CC-Anbieter eine Möglichkeit an, indem sie eine Art Token von der ursprünglichen Zahlung speichern, ohne die Kartennummer zu behalten (Sie könnten einfach die letzten 4 Ziffern behalten) dem Kunden anzeigen, damit sie wissen, welche Karte gespeichert ist).

Wirklich, mach es einfach nicht!

Außerdem sollten Sie niemals den CCV-Code behalten.

Answer 8

Vergessen Sie hier nicht die Integrität. Es gibt Fälschungsangriffe gegen Standard-Krypto, wenn der Angreifer den Schlüssel nicht kennt, aber den Geheimtext manipulieren kann. Diese können besonders böse sein, wenn:

• kurze Strings Verschlüsselung
• mit bekannten Teil

Das ist genau der Fall für Kreditkarten. Daher kann es gefährlich sein, System.Security.Cryptography AES oder 3DES im CBC-Modus zu verwenden, ohne die eigene Prüfsumme zu übertragen. Lesen: Es besteht die Möglichkeit, dass ein Angreifer ohne den geheimen Schlüssel eine Kreditkartennummer durch eine andere ersetzt.

Answer 9

Wenn Sie ein Zahlungsgateway eines Drittanbieters verwenden, müssen Sie die Nummern nicht speichern.

Es gibt keinen Sinn.

Answer 10

Verschlüsseln Sie die Kreditkarte mit einem öffentlichen Schlüssel. Geben Sie den privaten Schlüssel nur dem Zahlungsprozessorcomputer. Die Zahlungsprozessormaschine kann dann die Datenbank abfragen und die Arbeit ausführen, und niemand sonst, auch nicht die Maschine, die den Eintrag hinzugefügt hat, kann sie entschlüsseln.

Etwas wie OpenSSL_seal PHP, wenn Sie vielleicht mit einem anderen Algorithmus möchten.