c# - Almacenamiento de detalles de la tarjeta de crédito
security encryption (10)
Acordé que debes evitar almacenar los datos si puedes. ¿Pero tal vez eres ese tercero? Si es así, familiarícese con los PCI-DSS . Mire un poco en el sitio y encontrará las medidas de seguridad que debe implementar.
Tengo un requisito empresarial que me obliga a almacenar los detalles completos de la tarjeta de crédito de un cliente (número, nombre, fecha de vencimiento, CVV2) durante un período corto de tiempo.
Justificación: si un cliente llama para pedir un producto y su tarjeta de crédito es rechazada en el acto, es probable que pierda la venta. Si toma sus datos, agradézcales la transacción y luego descubra que la tarjeta no es aceptada, puede llamarlos por teléfono y es más probable que encuentren otra forma de pagar el producto. Si se acepta la tarjeta de crédito, borre los detalles del pedido.
No puedo cambiar esto. El sistema existente almacena los detalles de la tarjeta de crédito en texto claro, y en el nuevo sistema que estoy construyendo para reemplazar esto, claramente no voy a replicar esto.
Mi pregunta, entonces, es cómo puedo almacenar de manera segura una tarjeta de crédito por un corto período de tiempo. Obviamente quiero algún tipo de encriptación, pero ¿cuál es la mejor manera de hacer esto?
Entorno: C #, WinForms, SQL-Server.
Andrew, necesitas entender el PCI-DSS , no es una tarea pequeña. Personalmente, me parece extremadamente vago, pero esto es lo que entiendo.
En primer lugar, del escenario que describes, intentaría autorizar la tarjeta por el monto total y luego, si eso no funciona, almacenaría la información del cliente (pero no los datos del titular de la tarjeta) para que alguien pueda contactar al usuario. Cuando solía trabajar, algunos de nuestros clientes solo cobraban $ 1.00 y luego anulaban la transacción inmediatamente, solo para asegurarse de que la tarjeta era válida. Luego procesaban todas las órdenes manualmente.
Donde tendrá que almacenar el número se encuentra en una autorización exitosa. El único número que necesita es el número de tarjeta de crédito y el código de transacción (al menos con cada puerta de enlace con la que he trabajado).
El estándar, la última vez que lo analicé, no es específico de los algoritmos de encriptación, sino que deja en claro que debería ser un cifrado actualmente irrompible.
Ahora, una cosa que no puede hacer es almacenar el CCV luego de la autorización. Según tengo entendido, puede almacenarlo antes de la autorización, pero nunca podría obtener a nadie que lo escriba por escrito. Básicamente, usted autoriza la tarjeta, será mejor que la limpie.
Y no es ilegal en este momento, pero si te clavan, te harán caer el martillo. Tienen la autoridad de nivelar las multas pesadas contra usted, pero parece que lo que generalmente hacen es ponerlo en reparación. Si no cumple, no sé qué sucede porque todos los que he escuchado que esto sucedió cumplieron. Pero luego realmente suben tu botín con un microscopio.
En última instancia, creo que su único palo que realmente tienen es evitar que aceptes tarjetas de crédito. La mayoría de los comerciantes con los que he trabajado estaban asustados de eso exactamente.
Básicamente evite tomar la responsabilidad de guardar los detalles CC de su lado, sin embargo, puedo asumir que está utilizando un servicio de terceros para realizar su transacción como PayPal / Verisign o lo que sea, la mayoría de ellos tienen API que le permite guardar CC credenciales a su lado, y le devuelven una clave que luego puede usar para completar o iniciar transacciones, para que se encargue de la parte difícil, mientras que todo lo que tiene que hacer es almacenar esta clave de cadena en su base de datos.
Cuesta alrededor de $ 30,000 para cumplir con los requisitos y poder hacer ese tipo de cosas. Es mejor utilizar un servicio de pago de un tercero. Personalmente, recomiendo Element Express, y tienen una solución "Hosted" que evita el cumplimiento de PCI-DSS PAPDB. ¡He tenido que convertir esto para mis propias aplicaciones, incluso una máquina de punto de venta! Es un gran dolor, pero somos una empresa pequeña.
El enlace anterior contiene buena información sobre los costos asociados con el cumplimiento. Hemos tenido clientes que nos piden que guardemos números de tarjetas de crédito, y no lo haremos porque también podríamos ser multados. No está bien. No te abras a la responsabilidad.
Editar:
Además, si decide guardar la información de la tarjeta de crédito, definitivamente debe considerar los formularios de cifrado que va a utilizar. Simétrico? Asimétrico?
Si realiza el cifrado simétrico (clave de acceso), entonces se abrirá a algunas vulnerabilidades de seguridad graves si el servidor (sitio) que tiene la clave (necesaria para cifrar) se ve comprometida de alguna manera. Recuerde, incluso el código compilado no ocultará una clave de texto.
Si utiliza el cifrado asimétrico (pares de claves públicas / privadas), se encontrará con algunos problemas adicionales, pero si el servidor público principal se ve comprometido, solo tendrán la clave pública , y si también tienen acceso a su base de datos ... no serán capaz de criticar los contenidos.
La pregunta es, ¿dónde almacena la clave privada? ¿Alguien tiene que pegarlo desde sus computadoras locales cuando ejecuta las funciones administrativas? Tiene una aplicación separada que se ejecuta en el escritorio para ver las órdenes, etc.
Hay muchas cosas para tener en cuenta.
Nota final: utilice una pasarela de pago (Element Express, Authorize.NET, Paypal, etc.) y no almacene ninguna información de tarjeta de crédito a nivel local. :PAG
Aquí hay un enlace sobre el uso de Cifrado asimétrico X509 en C #: http://www.csharpbydesign.com/2008/04/asymmetric-key-encryption-with.html
No creo que en realidad sea ilegal almacenar información de CVV (en el sentido de que va en contra de cualquier ley), pero viola las reglas de la industria de tarjetas de pago y podría imponer cualquier cantidad de sanciones diferentes. Por lo tanto, sus requisitos podrían resultar en que no pueda aceptar tarjetas de crédito ;-(
Si solo desea almacenar la cadena por un corto período de tiempo en la memoria, puede echar un vistazo a System.Security.SecureString .
Tomado de esta answer :
Los valores de SecureString se almacenan cifrados (enmascarados, en su lugar), pero lo más importante es que nunca se intercambian en el disco y se pueden eliminar de inmediato cuando haya terminado con ellos.
Son difíciles de usar porque solo puedes construirlos de a uno por vez (para animarte a construirlos al capturar las teclas mientras el usuario escribe su contraseña), y necesitas tres líneas de código para recuperar y luego borrar su texto plano, pero cuando se usan adecuadamente, pueden hacer que un programa sea más seguro al evitar la vulnerabilidad de la memoria virtual.
Al final del ejemplo, SecureString se convierte en una cadena administrada regular, lo que la vuelve vulnerable nuevamente (asegúrese de utilizar el patrón try-catch-finally para poner a cero la cadena una vez que haya terminado con ella). El uso de SecureString consiste en reducir la superficie de ataque limitando el número de copias que Garbage Collector hará del valor y reduciendo la probabilidad de que se escriba en el archivo swap.
// Make a SecureString
SecureString sPassphrase = new SecureString();
Console.WriteLine("Please enter your passphrase");
ConsoleKeyInfo input = Console.ReadKey(true);
while (input.Key != ConsoleKey.Enter)
{
sPassphrase.AppendChar(input.KeyChar);
Console.Write(''*'');
input = Console.ReadKey(true);
}
sPassphrase.MakeReadOnly();
// Recover plaintext from a SecureString
// Marshal is in the System.Runtime.InteropServices namespace
try {
IntPtr ptrPassphrase = Marshal.SecureStringToBSTR(sPassphrase);
string uPassphrase = Marshal.PtrToStringUni(ptrPassphrase);
// ... use the string ...
}
catch {
// error handling
}
finally {
Marshal.ZeroFreeBSTR(ptrPassphrase);
}
Si va a almacenar información de la tarjeta de crédito, realmente necesita cumplir con PCI o simplemente está buscando problemas.
Habiendo dicho eso, mire la encriptación de nivel celular disponible en SQL Server 2005 y posteriores. Casualmente :) Hace poco presenté una presentación con ejemplos de T-SQL sobre encriptación con SQL Server 2005/2008 disponible aquí: http://moss.bennettadelson.com/Lists/Events/Attachments/9/June2008.zip (Ubicación del enlace actualizada) 23 de diciembre de 2008)
Tengo una publicación de blog que trata sobre esta situación exacta de almacenamiento de datos confidenciales en la base de datos. La publicación de blog utiliza una clase String Encryptor que construí usando un algoritmo Triple DES pero puede conectar la suya si así lo desea.
La publicación del blog contiene el video y el código fuente que se utilizó. Puede verificarlo en http://www.wrightin.gs/2008/11/how-to-encryptdecrypt-sensitive-column-contents-in-nhibernateactive-record-video.html . Creo que definitivamente resolverá tu problema.
Veamos el requerimiento un poco diferente. Actualmente se ve así:
Como propietario de un producto para el sitio web X, quiero que el sistema almacene temporalmente los detalles de un cliente CC para que pueda recuperar una venta que fue rechazada por la empresa CC.
Las personas tienden a pensar así y solicitan las características de esa manera. Ahora creo que su requisito se describe más cómodamente de la siguiente manera:
Como usuario, quiero que el sitio web X pueda reintentar el pago de mi compra, así que no tengo la molestia de tener que pasar por el proceso de pago porque es un verdadero dolor en el ...
Entonces, ¿no hay ningún requisito explícito para almacenar algo (de tu lado) está allí? Esto solo implica
Los proveedores de pago pueden proporcionar API programáticas a su cuenta de comerciante y la posibilidad de intentar una nueva autenticación en un intento rechazado. creo que @bashmohandes eludió a esto antes
No todos los proveedores de pagos pueden hacer esto, sin embargo, creo que depende de sus relaciones con los bancos involucrados. Eso es lo que quieres evitar, es decir. tener una relación cercana con los bancos.
Escenario 1: Suponiendo que todo lo que dije es verdad
No tiene que almacenar nada más que una referencia al intento de autorización. Algunos proveedores de pago incluso te ofrecen una herramienta de oficina de escritorio para que no tengas que hacer la tuya para realizar nuevas autorizaciones. Creo que paygate hace esto
Creo que su mejor opción es entrevistar a varios proveedores de pagos. deberían saber esto como la palma de sus manos. Esto es potencialmente una solución de código cero
Escenario 2: Suponiendo que estoy totalmente equivocado, pero legalmente este almacenamiento de CC está bien
Entonces debes almacenar esos datos en algún lugar temporalmente. Yo aconsejo:
- utilice un método de encriptación bidireccional (naturalmente) que no sea específico del vendedor para que pueda usar cualquier idioma / plataforma para encriptar / descifrar
- desacoplar el servicio de cifrado / descifrado de su aplicación y tratarlo como una caja negra
- utilizar claves públicas / privadas para la autenticación de este servicio
- pon esta máquina en una red privada con sus propias reglas elevadas de firewall (no tiene que ser un firewall de hardware pero el hardware es mejor)
- haga que sus servidores de aplicaciones se comuniquen con esta máquina a través de ssl (podría obtener un certificado autofirmado dado que está en su LAN privada)
Todo lo que he sugerido en el escenario 2 son los obstáculos, pero finalmente la persistencia gana la carrera para llegar a sus datos. La única manera de obtener datos absolutamente seguros es desconectando tu servidor del éter, pero esa opción es un poco radical :-)
El escenario 1 estaría bien. ¿No es así?
¡Considera tus registros de t!
Si le explica a su cliente el impacto total (y los requisitos correctivos si se descubren fuera de cumplimiento) entonces confíe en mí, sus ''requisitos comerciales'' cambiarán muy rápidamente.
Si debe almacenar el número de la tarjeta de crédito (y anticipo la idea de que no hay un escenario razonable donde debería) y tiene la intención de utilizar un cifrado nativo integrado en su base de datos, considere esto: ¿qué ocurre con los registros de transacciones?
Si sus registros de transacciones podrían reflejar un número de tarjeta de crédito en claro, entonces está fuera de cumplimiento y debe presupuestar una auditoría forense de $ 10,000 a $ 50,000 en su sitio si lo atrapan. Presupuesto para su propio abogado en caso de que su cliente lo demande porque debería haber sabido todo esto.
Entonces, si va a almacenar un número de tarjeta de crédito, ejecute el cifrado en el código para que los registros de transacciones (insertar o actualizar) reflejen una cadena cifrada, no el número de tarjeta en el claro.
Y ni siquiera tiene un campo o columna en su base de datos para CVV - encriptado o no - esa auditoría forense revelará esto (también lo harán los registros) y entonces su cliente tendrá GRANDES y GRANDES problemas. Pagarán una multa y podrían perder su capacidad de aceptar tarjetas de crédito. Su abogado estará muy feliz.