ASP.NET MVC - Secure almacenamiento temporal de datos de tarjeta de crédito

Question

Tengo un proceso de compra de un carro de compras que está almacenando datos de la tarjeta de crédito en la sesión para la recuperación una vez que el usuario finaliza la compra. El proceso de compra está configurado de tal manera que el usuario introduce la tarjeta de crédito, visita una página de confirmación y luego finaliza el pedido. La confirmación y acciones de finalización son las dos únicas acciones que necesitan acceso a los datos y la tarjeta de crédito para estar seguro todos los demás acciones deben desprenderse de ella.

A falta de hacer la reflexión en un controlador de base para comprobar la acción actual, el usuario está llamando, no puedo pensar en una manera elegante para descartar los datos de las solicitudes no permitidos. Además, si el usuario no puede hacer otra petición después de introducir los datos que se quedarán en la sesión hasta que vuelvan a la página web- cada vez que eso ocurre. Una sugerencia que me ofrecieron fue la encriptación de los datos en un campo oculto y confiando en el billete SSL para evitar el almacenamiento en caché el marcado. Este parece ser un enfoque bastante seguro, pero yo no gusta mucho la idea de colocar los datos de la tarjeta de crédito en un lugar accesible al usuario cifrada o no. Almacenar en la base de datos está fuera porque el cliente no quiere que los datos de tarjetas de crédito guardan.?

¿Cuál es el enfoque ideal para persistir temporalmente los datos sensibles como información de tarjetas de crédito a través de más de una solicitud de página?

---

Tal vez alguien me puede decir si este es un enfoque suficiente. He puesto mi carrito que se almacena en la sesión para tener un GUID único genera cada vez que el objeto es renovada y que Guid se utiliza como una clave para cifrar y descifrar los datos de la tarjeta de crédito que estoy serializar con el Rijndael algoritmo . La tarjeta de datos cifrados se pasa entonces al usuario en un campo oculto y deserializar después se hace clic en Finalizar. El resultado final es una cadena muy parecido a esto:

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

La mejor manera de manejar esta situación es utilizar un servicio de pago que admite dos cosas:

1. Autorización -.> Semántica de terminación
2. Tokenization

Autorización le permite reservar la cantidad de carga designada en el momento en que se reciba la información de pago, y luego avance permite que se comprometa el cargo al lote de pagos una vez que el pago / orden se confirma. Si la orden es cancelada, usted no tiene que emitir una Terminación y también se puede tratar de eliminar la autorización también.

En cuanto tokenización, la mayoría de las puertas de enlace que soportan el método de manejo de pagos devolverá un contador, típicamente un ID numérico, para la transacción pendiente antes mencionada. El token puede entonces ser manejado como desee, ya que no tiene valor para nadie, sin acceso a sus credenciales de autenticación en el gateway. Esto transfiere la carga de la seguridad de la puerta de entrada también.

Almacenamiento de la información de la tarjeta de crédito real de cualquier manera distinta de la retransmisión de un cargo a una puerta de entrada / procesador es una mala idea. Más allá de los problemas de la obtención de los datos, esto también va a poner su aplicación en el alcance de almacenamiento de información de la tarjeta de PCI / PABP, lo que implica un montón de reglas y regulaciones que usted no querrá que tratar en su aplicación. Creo que también es una cuota regulatoria que se impondrá en el próximo año para las aplicaciones compatibles, según se dice $ 10k USD. Todo esto es probable que no vale la pena que usted o su cliente.

Por último, durante el procesamiento intermedio (en páginas / eventos / manejadores de ruta), se puede utilizar un SecureString para almacenar el contenido de los datos hasta que ya no los necesita.

SecureString clase (System.Security) @ MSDN

Answer 2

¿Qué pasa con el uso de TempData? Que había necesidad de poner el valor de nuevo en TempData entre la confirmación y las acciones de finalización, pero al menos se descartarán con cada solicitud. Tenga en cuenta que TempData utiliza la sesión para el almacenamiento así que no es más segura mientras se está almacenando, pero tiene la función de eliminación automática. Yo, también, resistiría a almacenar el número de la página. Sospecho que esto viola las normas PCI.

Otra alternativa sería la de almacenar la información de la tarjeta en una base de datos. Si se mantiene en absoluto en su aplicación es probable que ya sujetos a las normas PCI de todos modos. Almacenarla en la base de datos hace que sea más fácil, ya continuación, sólo tiene que poner la tarjeta Identificación de facturación en las solicitudes posteriores. Esto fácilmente podría estar en un campo oculto.

Answer 3

¿En qué país se basa en este y lo que las compañías de tarjetas de crédito están involucrados? Todo el enfoque de tener que enviar los números de tarjetas de crédito completos de vuelta al cliente (en cualquier forma) hace que este sonido como que no se han ocupado de tratamiento de tarjetas de crédito profesional (por favor no tomar esto como un insulto).

Es el cliente dispuesto a ir en contra de las reglas colectivas Visa / MasterCard / AMC / de Discover para el procesamiento en línea de tarjetas de crédito (PCI DSS)? Su cliente podría terminar siendo impedimento en las principales compañías de tarjetas de crédito de hacer transacciones con ellos. En general, es una muy mala idea para tratar de rodar su propia solución de manejo de tarjetas de crédito en línea - es peor que rodar su propio algoritmo de cifrado, ya que puede haber multas graves aplicados a su cliente (letra pequeña en su acuerdo comercial). Una verdadera solución PCI DSS requiere decenas de miles de dólares en certificaciones y auditorías para asegurarse de que maneja los datos de la tarjeta de crédito de una manera realmente segura -. Esto es lo que casi todo el mundo utiliza un procesador en línea existente