ASP.NET MVC - Sichere Vorübergehende Speicherung der Kreditkartendaten

Question

Ich habe einen checkout-Prozess für einen Warenkorb, die ist derzeit die Speicherung von Kreditkarten-Daten in der Sitzung zum Abruf, sobald der Benutzer schließt den Kauf.Der Kauf-Prozess ist so angelegt, dass der Benutzer die Eingänge der Kreditkarte, Blick auf eine Bestätigungs-Seite, und dann schließt der Bestellung.Die Bestätigung und Abschluss Aktionen sind nur zwei Maßnahmen, die Zugriff auf die Daten der Kreditkarte und sicher alle anderen Aktionen, sollte es zu verwerfen.

Kurze tun Reflexion in einem Basis-controller zu überprüfen Sie die aktuelle Aktion, die der Benutzer ruft, ich kann nicht denken Sie an eine elegante Weise zu entledigen, die Daten auf der unzulässigen Anfragen.Zusätzlich, wenn der Benutzer nicht zu machen eine weitere Anfrage nach Eingabe der Daten wird Verweilen in der Sitzung, bis Sie kommen zurück zu den website - wenn das passiert.Ein Vorschlag, den ich angeboten wurde, war die Verschlüsselung der Daten in einem versteckten Bereich und das verlassen auf den SSL ticket Cachen zu verhindern, das markup.Dies scheint eine ziemlich sichere Ansatz, aber ich weiß nicht, wie viel die Idee, die Daten der Kreditkarte in einem für den Benutzer zugänglichen Speicherort verschlüsselt oder nicht.Die Speicherung in der Datenbank aus, weil die Kunden nicht wollen, Kreditkarte Daten gespeichert.

Was ist der ideale Ansatz, um vorübergehend anhaltenden sensiblen Daten wie Kreditkarten-Informationen, die über mehr als eine Seite anfordern?

---

Vielleicht kann mir jemand sagen, ob dies ein ausreichender Ansatz.Ich habe meinen Einkaufswagen, die in der session gespeichert, um eine eindeutige Guid generiert jedes mal, wenn das Objekt ist newed und die Guid wird als ein Schlüssel zum verschlüsseln und entschlüsseln der Daten der Kreditkarte, die ich serialisieren mit dem Rijndael-Algorithmus.Die verschlüsselten Daten dann an die Benutzer in einem ausgeblendeten Feld und deserialisiert wird nach abschließen geklickt wird.Das Ergebnis ist ein string, so ähnlich wie diese:

VREZ%2bWRPsfxhNuOMVUBnWpE%2f0AaX4hPgppO4hHpCvvwt%2fMQu0hxqA%2fCJO%2faOEi%2bX3n9%2fP923mVestb7r8%2bjkSVZDVccd2AJzCr6ak7bbZg8%3d

---

public static string EncryptQueryString(object queryString, Guid encryptionKey)
{
    try
    {
        byte[] key = Encoding.UTF8.GetBytes(ShortGuid.Encode(encryptionKey).Truncate(16));//must be 16 chars
        var rijndael = new RijndaelManaged
                           {
                               BlockSize = 128,
                               IV = key,
                               KeySize = 128,
                               Key = key
                           };

        ICryptoTransform transform = rijndael.CreateEncryptor();

        using (var ms = new MemoryStream())
        {
            using (var cs = new CryptoStream(ms, transform, CryptoStreamMode.Write))
            {
                byte[] buffer = Encoding.UTF8.GetBytes(queryString.ToString());

                cs.Write(buffer, 0, buffer.Length);
                cs.FlushFinalBlock();
                cs.Close();
            }
            ms.Close();
            return HttpUtility.UrlEncode(Convert.ToBase64String(ms.ToArray()));
        }
    }
    catch
    {
        return null;
    }
}

Answer 1

Der beste Weg, um dieses Szenario zu behandeln ist, einen Zahlungsdienst zu verwenden, die Stütze zwei Dinge:

1. Authorization -.> Fertigstellung Semantik
2. Tokenisierung

Authorization ermöglicht es Ihnen, die bestimmte Ladungsmenge zum Zeitpunkt der Zahlungsinformationen empfangen wird, reservieren und dann Fertigstellung können Sie die Ladung auf die Zahlung Charge verpflichten, sobald die Zahlung / Bestellung bestätigt wird. Wenn die Bestellung storniert wird, Sie nicht über einen Abschluss erteilen und Sie können auch als auch die Berechtigung zu löschen versuchen.

In Bezug auf tokenization, die meisten Gateways, die das oben genannte Verfahren zur Handhabung von Zahlungen unterstützen werden wieder ein Token, typischerweise eine numerische ID, für die anstehende Transaktion. Der Token kann dann behandelt werden, wie Sie wollen, da sie keinen Wert für jeden, ohne Zugriff auf Ihre Authentifizierungsdaten am Gateway hat. Diese überträgt die Last der Sicherheit an das Gateway als auch.

Das Speichern der aktuellen Kreditkarteninformationen in irgendeiner Art und Weise als eine Ladung zu einem Gateway / Prozessor Weiterleitung ist eine schlechte Idee. Über die Probleme, die Daten zu sichern, wird dies auch Ihre Anwendung in dem Karteninformationsspeicherumfang für PCI / PABP setzen, die eine Menge von Regeln und Vorschriften führen dazu, dass Sie nicht mit wollen auch in Ihrer Anwendung beschäftigen. Ich glaube, es ist auch eine regulatorische Gebühr, die für kompatible Anwendungen, angeblich $ 10k USD im kommenden Jahr eingeführt werden. wahrscheinlich nicht wert All dies ist das Problem für Sie oder Ihre Kunden.

Last, während Zwischenverarbeitung (in-Seite / Event / route Handler), können Sie einen Secure verwenden den Inhalt der Daten zu halten, bis Sie nicht mehr benötigen.

Secure Klasse (System.Security) @ MSDN

Answer 2

Was ist TempData mit? Sie müßten den Wert wieder in TempData zwischen der Bestätigung und Abschluss Aktionen setzen, aber zumindest wird es mit jeder Anforderung verworfen werden. Beachten Sie, dass TempData die Session für Speicher verwendet, so dass es nicht mehr ist sicher, während es gespeichert wird ist, aber es die automatische Löschfunktion hat. Ich würde auch wieder auf der Seite, die Anzahl zu speichern. Ich vermute, dass dies die PCI-Regeln verstößt.

Eine weitere Alternative wäre es, die Kartendaten in einer Datenbank zu speichern. Wenn Sie es überhaupt in der Anwendung zu halten sind Sie wahrscheinlich bereits unter den PCI-Regeln sowieso. es in der DB Speicherung macht es einfacher als dann nur Sie die Abrechnungskarte ID in nachfolgenden Anforderungen stellen müssen. Diese leicht in einem versteckten Bereich sein könnte.

Answer 3

Welches Land ist das und welche Kreditkarte Unternehmen beteiligt sind?Der gesamte Ansatz der tatsächlich senden die vollständige Kreditkartennummer an den client zurück (in welcher form auch immer) macht das klingt wie Sie noch nicht mit befasst professionelle Kredit-Karte-Handhabung (bitte nicht als Beleidigung).

Ist Ihr Kunde bereit, in Konflikt geraten Visa/MasterCard/AMC/Entdecken Sie die gemeinsamen Regeln für die online-Verarbeitung von Kreditkarten (PCI DSS)?Ihr Kunde könnte am Ende wird ihm von den großen Kreditkarten-Unternehmen aus Transaktionen mit Ihnen.Im Allgemeinen ist es eine sehr schlechte Idee zu versuchen, Ihre eigenen Rollen online credit card handling-Lösung - es ist schlimmer, dann Rollen Sie Ihre eigenen kryptographischen Algorithmus, es kann zu schweren Geldstrafen angewendet, um Ihren client (Kleingedruckte in Ihrem merchant-Vertrag).Eine echte PCI-DSS-Lösung erfordert Zehntausende von Dollar in Zertifizierungen und audits, um sicherzustellen, dass es Griffe die Kreditkartendaten in einer wirklich sicheren Weise - das ist der Grund, warum fast jeder nutzt ein bestehendes online-Prozessor.