Usando un lado del navegador de cifrado de clave pública para evitar el cumplimiento de PCI

2

Estamos desarrollando una aplicación web en la que ciertos usuarios no registrados (clientes) deben enviar los datos de su tarjeta de crédito a otros usuarios (comerciantes), que, suponemos, son compatibles con PCI.

Estamos estudiando el cumplimiento de PCI, pero el proceso seguramente necesitará mucho tiempo. Por lo tanto, estamos investigando otras soluciones que no requieren que obtengamos una certificación y nos protegen contra el robo de datos razonables.

Nuestro plan es:

  • Haga que el comerciante genere una clave privada y pública
  • Almacene la clave privada dentro de su navegador usando localstorage (y proporcione un medio para hacer una copia de seguridad)
  • Proporcione la clave pública en el formulario utilizado por un cliente
  • Antes de que el cliente envíe los datos, cifre todo con la clave pública del comerciante
  • Almacene los datos cifrados en nuestro servidor
  • Proporcione los datos cifrados al comerciante
  • Haga que el comerciante descifre los datos en su navegador usando su clave privada

La idea era utilizar JavaScript y la biblioteca jsencrypt .

¿Ve problemas de seguridad en este flujo de trabajo? ¿Crees que todavía necesitamos el cumplimiento de PCI cuando empleamos un sistema así? El razonamiento es que, para cualquier persona sin la clave privada, esos son solo bytes aleatorios.

El único ataque que se me ocurre es que alguien esté comprometiendo el servidor y reemplazando una clave pública de comerciante con su propia clave. Pero también podría robar una ficha para otra pasarela de pago y falsificar la comunicación necesaria para hacer algo desagradable.

Sabemos de servicios como Paymill, Braintree y Stripe (que ofrecen bibliotecas bastante buenas para el cliente) pero no son adecuados para nuestra solución (o mejor: son alternativas que pondremos a disposición de los comerciantes, pero deberían depender de ellos para decidir).

Gracias de antemano

EDIT: Estoy totalmente de acuerdo con ustedes y prefiero trabajar con soluciones de terceros.

El problema es que estamos trabajando en un mercado en el que la mayoría de nuestros competidores son pequeñas empresas que trabajan sin el cumplimiento de PCI (¡y la mayoría de ellos incluso sin HTTPS!). Nuestros competidores simplemente reciben datos de CC, los almacenan y dan acceso a los usuarios.

Sabemos acerca de los riesgos de este enfoque, pero los usuarios no lo hacen y prefieren sus soluciones a las nuestras porque prefieren tener toda la información de CC, en lugar de solo tener botones para ejecutar acciones.

    
pregunta framp 01.08.2014 - 02:35
fuente

5 respuestas

7

(Divulgación, trabajo en Braintree)

Si un servidor proporciona un formulario en el que los clientes ingresarán los números de las tarjetas de crédito, ese servidor se encuentra dentro del alcance de PCI. Esto es independiente de si encripta los datos en el navegador. El razonamiento aquí es que un atacante puede modificar la página que se envía al navegador para extraer datos de la tarjeta de crédito de la página DOM antes del cifrado.

Necesitaría trabajar con un proveedor de acceso de seguridad calificado (QSA) o con su proveedor de cuenta de comerciante para saber cómo será su proceso de PCI. Si está procesando menos de 1 millón de transacciones, probablemente sea un proceso de autoevaluación. La determinación de qué cuestionario de autoevaluación (SAQ) debe completar se basa en la cantidad de acceso a los datos del titular de la tarjeta y si la almacena.

    
respondido por el John Downey 01.08.2014 - 03:14
fuente
1

Hay muchos procesadores de pago de terceros que le permiten usar de forma transparente sus formularios y procesos, incluidos paypal, google, worldpay y muchos otros. Esto puede ser bastante transparente para el usuario si está configurado correctamente. Esta es la mejor manera de evitar los requisitos de PCI: nunca procese la información de la tarjeta ...

Hay algunos problemas con tu esquema:

  • Primero, debe tener la seguridad de que la página y el código no han sido manipulados, incluida la inclusión de bibliotecas dependientes. Por lo tanto, HTTPS como mínimo, pero también buenas prácticas de control de cambios, etc.
  • En segundo lugar, cualquier XSS, XSF, MITB en el cliente podría robar su clave privada.

Incluso las grandes organizaciones suelen optar por mitigar el riesgo de manejo de la tarjeta mediante el uso de procesadores de terceros ...

    
respondido por el Andy Boura 01.08.2014 - 10:16
fuente
1

Si está almacenando los datos de la tarjeta en sus propios servidores, incluso si están cifrados y no tiene la clave para descifrarlos, entonces debe cumplir con la versión más elaborada de los estándares PCI y usar SAQ- RE. Le sugeriría que no almacene los datos de la tarjeta en absoluto, pero que el comerciante los guarde por usted. Entonces solo deberías usar SAQ-C.

    
respondido por el Mike Scott 01.08.2014 - 10:29
fuente
0

John Downey ha dado la mejor respuesta, pero solo para ampliar el problema más grande con esta parte del flujo de trabajo:

  

Haga que el comerciante genere una clave privada y pública

     

Almacene la clave privada dentro de su navegador usando localstorage

Entonces, digamos que tienes una docena de comerciantes con claves públicas y privadas almacenadas en sus navegadores.

Usted no almacena sus claves pero su servidor tiene algún tipo de agujero de seguridad.

Un atacante obtiene el control de su servidor.

El atacante modifica las páginas que usarán tus comerciantes, agregando algunos de sus propios javascript / etc.

La próxima vez que los comerciantes inicien sesión, el javascript recupera su clave privada y la envía al atacante.

El atacante ahora tiene casi todas las claves privadas.

Todos los datos enviados a los comerciantes ahora están abiertos para ellos porque pudieron obtener el control de su servidor.

    
respondido por el Murphy 01.08.2014 - 18:48
fuente
0

Las normas PCI existen por una razón. Si bien el proceso para alcanzar ese nivel de seguridad puede ser arduo, es necesario proteger los datos de su cliente . Seamos claros al respecto; no solo son sus datos, son los datos que sus clientes le han confiado a su atención, y si no los asegura utilizando las mejores prácticas razonables, su compañía se está abriendo a enormes niveles de responsabilidad.

Si no desea hacer todo lo relacionado con el procesamiento de pagos, es mucho mejor trabajar con un proveedor de pagos. Pueden hacer que el proceso de pago sea fácil y sin problemas en estos días, con una pena mínima para sus clientes.

    
respondido por el Byron Jones 12.06.2015 - 22:59
fuente

Lea otras preguntas en las etiquetas