Preocupaciones de seguridad con el sistema de prepago

6

Estoy pensando en establecer un sistema de prepago para la industria minorista de alimentos. Los minoristas podrán generar códigos aleatorios de 10 dígitos y proporcionarlos a los clientes para que ingresen en una aplicación para obtener el valor asignado al código. Mi base de datos es similar a la siguiente

  +----+-----------+-------------+-----------+-------+
  | ID | code      | activated   | user      | value |
  +----+-----------+-------------+-----------+-------+
  |  1 | iijwd923j |     0       |           |  10   |
  +----+-----------+-------------+-----------+-------+
  |  2 | aidwd923j |     0       |           |  10   |
  +----+-----------+-------------+-----------+-------+
  |  3 | jksjwdijk |     0       |           |  10   |
  +----+-----------+-------------+-----------+-------+
  |  4 | jiejdedow |     0       |           |  10   |
  +----+-----------+-------------+-----------+-------+
  |  5 | iwqjdwdqd |     0       |           |  10   |
  +----+-----------+-------------+-----------+-------+

Se omiten muchas columnas ya que no se requieren aquí. Cuando el minorista genera el código, este se revisa y se sala en sal antes de ingresar a la base de datos. Cuando el código se ingresa en la aplicación, su identificación se asigna al código y se activa. El minorista también puede activar o desactivar el código si los códigos faltan. Esto lo hace el índice.

¿Prevén algún problema de seguridad aquí?

    
pregunta maxum 26.10.2012 - 07:45
fuente

2 respuestas

6

El principio básico se ve bastante bien.

Algunos pensamientos:

  • Cuando se usa un token, no lo elimines. Marque como usado, almacene una fecha "usada" y borre tokens antiguos después de 6 meses. De lo contrario, el mismo número de serie del token podría volver a crearse por accidente, ya que el sistema no tiene registro de que haya existido.
  • ¿Se puede ejecutar una instancia única de este sistema de prepago en varios sitios físicos? Si es así, tendrá que tomar en cuenta la sincronización de los datos, de lo contrario, un usuario podría reutilizar su token en otra máquina.
  • Si cada sistema de proveedor necesita comunicarse con algún tipo de estación base, necesitará una forma segura de hacerlo. La seguridad física en la forma de un cable Ethernet está bien en las tiendas pequeñas, pero vale la pena estar segura. Asegúrese de implementar SSL para dicho tráfico, con certificados de cliente y servidor instalados en las máquinas apropiadas.
  • Probablemente querrá vincular cada código a un proveedor específico, cuyo ID se genera aleatoriamente. De lo contrario, un asistente de tienda podría imprimir un montón de códigos e ir de compras a otro proveedor que utilice su sistema. ¡Asegúrese de que la generación de ID utilice un generador de números aleatorios de alta calidad!
  • Asegúrese de que se tomen las disposiciones de seguridad adecuadas para el sistema que ejecuta la base de datos. Bloquee la máquina con la política de grupo, habilite y configure adecuadamente el Firewall de Windows, instale un paquete antimalware (Microsoft Security Essentials es bueno si no le gusta la idea de ejecutar soluciones de terceros), etc.
  • Configure correctamente el software de su servidor de base de datos. Esto incluye asegurarse de que solo escuche localmente (no se vincule a 0.0.0.0) o que solo use canalizaciones locales si es posible. También debe usar credenciales seguras para el servidor y privilegios mínimos. Si es factible, reduzca todas las consultas a procedimientos almacenados y solo permita que la cuenta acceda a esos procedimientos, no le conceda privilegios en ninguna tabla.
  • Asegúrese de implementar un sistema de auditoría que registre al cajero que realizó la transacción, la hora, la identificación del pedido al que pertenecía, el precio total de la transacción en ese momento (¡los precios del producto cambian!), la identificación de la tienda, y el código de texto plano que se utilizó. No es necesario que asegure el código en este momento, es inútil.
  • En el caso de un reembolso en el que el cliente debe devolver su token, genere un nuevo token. Nunca vuelvas a usar el número de token anterior.
respondido por el Polynomial 26.10.2012 - 08:02
fuente
1

Me parece un buen enfoque.

Puede considerar si prevé la necesidad de resolución de disputas. Dependiendo de su aplicación, tal vez no sea necesario, pero creo que la resolución de conflictos y la cuenta de facturación representan una parte sustancial de la complejidad y el desafío de muchos sistemas de pago.

Creo que es posible que desee asociar cada código a un minorista específico, de modo que solo pueda canjearse en ese minorista, y así pueda ejecutar informes por minorista (por ejemplo, número de códigos creados, número canjeado, valor total pendiente, etc.).

    
respondido por el D.W. 26.10.2012 - 07:54
fuente

Lea otras preguntas en las etiquetas