Generando y asegurando códigos de tarjetas de regalo

Question

Generando y asegurando códigos de tarjetas de regalo

#1 de Therac (7 votos)
#2 de TTT (1 votos)
#3 de DoubleD (1 votos)
#4 de keithRozario (1 votos)
#5 de Mark (0 votos)

10

Estoy trabajando para una compañía que está generando códigos de tarjetas de regalo que se pueden usar para pagar productos en tiendas en línea.

Me pregunto cuál es la forma más segura de generar estos códigos de tarjetas de regalo. La longitud debe ser de 16 caracteres (aunque eso es negociable) y puede ser alfanumérica (aunque numérica sería más amigable para el cliente).

Por lo que puedo ver, la forma más segura de hacerlo es generar un código de tarjeta de regalo de una longitud específica con el siguiente código de Java:

static final String AB = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ";
static SecureRandom rnd = new SecureRandom();

String randomString( int len ){
   StringBuilder sb = new StringBuilder( len );
   for( int i = 0; i < len; i++ ) 
      sb.append( AB.charAt( rnd.nextInt(AB.length()) ) );
   return sb.toString();
}

Esto se ha tomado de la respuesta de desbordamiento de pila aquí . Quité las letras minúsculas de la cadena para hacerlas más fáciles de usar. Así que esto produce 36 ^ 16 combinaciones. Numérico solo sería 10 ^ 16 combinaciones. Creo que solo con el número sería suficiente, pero a menudo se enfatiza que, dada la creciente prevalencia del fraude con tarjetas de regalo, la cadena debe ser alfanumérica. Así que esa es la pregunta uno: ¿numérico o alfanumérico?

Cuando los usuarios usan las tarjetas de regalo en una tienda en línea para pagar bienes, se realiza una llamada a nuestra API que devuelve el saldo y la moneda de esa tarjeta de regalo. Dado que los códigos de las tarjetas de regalo se ingresan en servidores de terceros, estas tarjetas de regalo ahora están disponibles para las personas que tienen acceso a esos servidores. Obviamente, esto es un problema en el caso en que aún queda un saldo después de que un usuario haya canjeado parcialmente uno.

Una opción sería, cuando la llamada a nuestra API se realiza (con el código de la tarjeta de regalo) para obtener el saldo, devolvemos y guardamos en su tienda una cadena aleatoria que solo la tienda en línea puede usar cuando nos están facturando, lo igualaremos con el código de la tarjeta de regalo en nuestro sistema. El problema con eso es, presumiblemente, el código de la tarjeta de regalo que el usuario ingresa en el proceso de registro se registra en algún lugar de sus registros y es accesible para cualquier persona que tenga acceso a esos registros.

Otra opción es que renovemos el código de la tarjeta de regalo una vez que se haya canjeado parcialmente. Por lo tanto, el usuario obtiene esencialmente un nuevo código de tarjeta de regalo para el saldo y el anterior se cancela. Este es probablemente el más seguro, pero no tan fácil de usar. Entonces, esa es la segunda pregunta: ¿Cómo aseguramos los códigos de las tarjetas de regalo que solo se canjean parcialmente y aún tienen valor en ellos?

EDIT:

También tenemos una página de Verificación de saldo en la que un usuario ingresa un código de tarjeta de regalo y la moneda y el saldo se devuelven. Esto presumiblemente crea algunas preocupaciones de seguridad adicionales.

hash java e-commerce

pregunta Mark 03.04.2018 - 12:49

fuente

5 respuestas

Lea otras preguntas en las etiquetas hash java e-commerce

¿Cualquier navegador que admita script-nonce? ¿Puedo simplemente buscar-reemplazar y?

score 7 · Answer 1

Para evitar el fraude, necesita una probabilidad suficientemente baja de que el atacante adivine cualquier código válido. Para 1 millón de tarjetas, se calculará un código de 10 ^ 16 en el promedio de cada 10 ^ 10 intentos. Si su sitio es completamente seguro y su API es resistente a la fuerza bruta, el número debería ser suficiente para que el enfoque del fraude no sea rentable.

Pero es una seguridad muy frágil, y la protección contra hash a continuación será fácil de descifrar en una fuga de base de datos con un espacio de teclas tan pequeño. IOW, un atacante con acceso a su base de datos será capaz de forzar una gran cantidad de códigos válidos. Un código alfanumérico proporcionará una seguridad más robusta. También puedes comprometerte con un patrón para facilitar su uso.

Ya que en su sistema, el código es efectivamente tanto un inicio de sesión como una contraseña, para reducir sus fugas, necesita cambiar el protocolo de comunicación para eliminar la transmisión y el almacenamiento de códigos de texto simple.

El protocolo más simple para eso sería almacenar Salt1 y Sash1 = hash (Code + Salt1), luego generar hash (hash (Code + Salt1) + Salt2) del lado del cliente y verificarlo. Pero eso sigue siendo trivialmente vulnerable si su base de datos está en peligro, ya que el atacante solo necesita una lista de Hash1 válido para realizar compras a través de su API. También es lento, ya que debe marcar todos los códigos válidos para marcar uno.

Una solución más robusta es ejecutar el código a través de un PBKDF, que es una función lenta e irreversible, que produce un valor que puede almacenar. De esa manera, una fuga en la base de datos no proporcionará datos listos para simular a un usuario legítimo. Pero debe confiar en las tiendas para no almacenar el código y hacer cumplir las conexiones de solo https.

Es imposible hacer que este sistema sea seguro contra una tienda maliciosa que registra las entradas de los usuarios; si tienen el código completo, por definición son los dueños de la tarjeta. La única defensa es permitir solo el canje de códigos a través de un formulario cargado directamente desde su servidor. Si lo hace, nadie, excepto el usuario y su PBKDF, verá el código; la tienda solo recibe su respuesta de validación.

score 1 · Answer 2

Dado que los códigos de las tarjetas de regalo se ingresan en servidores de terceros, estas tarjetas de regalo ahora están disponibles para las personas con acceso a esos servidores.

Es cierto que los administradores del servidor pueden acceder a las tarjetas de regalo, pero también pueden acceder a los números de tarjetas de crédito que ingresan los usuarios en las tiendas en línea. Si puede confiar en una tienda en línea para recopilar un número de tarjeta de crédito sin hacer nada nefasto, ¿por qué no puede confiar en que ellos también recopilen una identificación de tarjeta de regalo? (O tal vez esté pensando que cuando un administrador roba números CC, ese no es su problema, pero si roban los códigos de las tarjetas de regalo, es su problema ...) Tal vez la verificación adecuada de sus comerciantes debe ser parte de su modelo comercial.

Su idea de cambiar el código de la tarjeta de regalo después de cada compra debería funcionar, pero ¿cómo le dice al usuario cuál es su nuevo código? Quizás pueda enviarles un correo electrónico notificándoles la transacción, incluir su saldo restante y proporcionarles un enlace para que inicien sesión y obtengan su nueva identificación de tarjeta de regalo. Estoy de acuerdo, sin embargo, que podría ser algo molesto para algunos usuarios. Realmente dependería de qué tan confiable parezca ser el comerciante, y el usuario podría saberlo mejor. Tal vez podría permitir que el usuario decida si desea habilitar la opción de restablecimiento, e incluso permitirle establecer un umbral por encima del cual se produce (por ejemplo, $ 50).

score 1 · Answer 3

Creo que hay un problema fundamental que no se puede abordar técnicamente. La mayoría de las medidas antifraude establecidas reducen el riesgo, pero debe aceptar que ocurrirá un fraude.

Esto es fundamentalmente un problema de confianza. Confía en las tiendas para que carguen el importe correcto de la tarjeta de regalo por cada transacción y solo para publicar las transacciones autorizadas por el usuario. También confía en que el usuario mantendrá la tarjeta en secreto.

Los problemas de confianza requieren auditoría. Al igual que con las tarjetas de crédito, existe un potencial de uso indebido por parte de terceros. Muchas de las reglas de PCI DSS que rodean a las tarjetas de crédito están diseñadas para minimizar el riesgo de fraude, pero incluso con esas reglas, la industria de las tarjetas de crédito enfrenta un riesgo sustancial de fraude. Para hacer frente a ese riesgo, el banco supervisa en busca de signos de fraude y los estados de cuenta están disponibles para los titulares de las tarjetas, por lo que también pueden revisar la actividad de la cuenta para detectar transacciones no autorizadas. No puede eliminar el riesgo de fraude, por lo que debe supervisar e informar sobre la actividad, y permitir que los usuarios hagan lo mismo.

La vigilancia y la capacidad de respuesta son las únicas soluciones a largo plazo. A pesar de las medidas de seguridad razonables, no puede evitar el fraude por completo. Si esto fuera posible, la industria de tarjetas de crédito ahorraría miles de millones de dólares anualmente. Ellos no pudieron hacerlo, y su compañía probablemente tampoco lo hará. Su empresa y los usuarios deben vigilar el abuso y tomar medidas correctivas según sea necesario. Si su compañía emite tarjetas de regalo, deben comprometerse con personal antifraude durante la vida del programa. Incluso si no busca un caso legal, se espera que proporcione un remedio a sus usuarios. . Alguien debe estar facultado para investigar y adjudicar reclamos de fraude.

Hay medidas de seguridad establecidas que puede implementar. La mayoría de las tarjetas de regalo comienzan con un saldo de cero y / o están inactivas hasta que se venden. El número de cuenta o CVV se debe ocultar hasta que se venda (ya sea sellado en un paquete a prueba de falsificaciones o detrás de un rasguño). En el punto de venta, la activación se basa en un número de serie en lugar de la ID de la tarjeta de regalo, y la ID de la tarjeta de regalo no se deriva de ese número de serie de ninguna manera discernible, o viceversa.

Los secretos se comparten, y eso rompe la mayor parte de la seguridad. Con las tarjetas de regalo y las tarjetas de crédito tradicionales, los usuarios suministran a terceros vendedores todo lo necesario para hacerse pasar por ellos. Este es un marcado contraste con los sistemas basados en blockchain que permiten a los usuarios mantener sus secretos confidenciales. Cuando se trata de un sistema fundamentalmente inseguro, debe implementar controles compensatorios o mitigaciones para esos riesgos. Entonces aceptas cualquier riesgo que quede y te quedas soldado.

score 1 · Answer 4

En el mundo de las tarjetas de crédito, cada transacción en línea donde un cliente ingresa sus números de tarjeta en un navegador, requiere el número de tarjeta Y el código CVV2. Por lo general, este es un código de 3 dígitos impreso en el reverso de la tarjeta. Se aconseja a los comerciantes que NUNCA guarden este número, pero pueden mantener el número de la tarjeta (con restricciones muy estrictas).

La analogía es que el número de la tarjeta es como un nombre de usuario, mientras que el CVV2 es como la contraseña (más o menos, quizás!). Su problema parece ser que solo confía en los números de tarjeta, que es como confiar en los nombres de usuario solo por seguridad. Este es un problema, debería haber alguna forma de autenticar la tarjeta, el número de la tarjeta es simplemente un identificador.

Mi sugerencia es agregar algún tipo de PIN a la transacción. El cliente debe proporcionar el PIN en la llamada a la API antes de que pueda ser aprobado. Ese PIN nunca debe almacenarse en los registros de los comerciantes. Si le preocupa esto, intente crear un PIN de una sola vez (OTP) que le envíe un SMS al cliente cuando se realiza una transacción, pero esto agrega una gran cantidad de complejidad, pero también elimina el riesgo de que los comerciantes reutilicen la tarjeta para otra transacción, ya que nunca tendrán la OTP.

Cambiar el número de la tarjeta es algo aún más difícil de hacer, y probablemente no sea el mejor viaje del cliente, no lo recomendaría.

score 0 · Answer 5

Revisé todas las respuestas y encontré una solución, teniendo en cuenta las sugerencias:

Generamos un enlace para enviar al usuario. La clave enviada en el enlace es una cadena alfanumérica aleatoria y está grabada (MD5 o algo similar), por lo que no puede ser revelada antes de ser guardada en la base de datos.
Cuando el usuario hace clic en el enlace, se redirige a nuestra página de destino, usamos la clave para obtener el pedido, verificamos el estado del pedido y si hay crédito en él, y si está bien, generamos un Código alfanumérico de 16 caracteres de longitud y envío a la interfaz de usuario. El código de 16 caracteres está recortado (de nuevo MD5) y se guarda en nuestra base de datos. Cada vez que un usuario hace clic en el enlace, ve un nuevo código de tarjeta de regalo como se genera en la marcha cada vez.
En el contrato con la tienda en línea, especificamos que no pueden registrar o guardar el código de la tarjeta de regalo en cualquier lugar (nuestros 2 clientes son grandes minoristas en línea bien conocidos)
En la página de pago de la tienda en línea de nuestro cliente, para pagar con nuestro código de tarjeta de regalo, el usuario proporciona el código de la tarjeta de regalo de 16 caracteres. Se envía a nuestros servidores y el saldo y un pago aleatorio I.D. Se devuelve a la tienda online. Este pago I.D se guarda en la tienda en línea como parte del pedido. Al completar el pedido, la tienda en línea envía una solicitud de API (con el ID de pago) a nuestros servidores para canjear el monto de la tarjeta de regalo (esta funcionalidad la compramos nosotros y la proporcionamos a la tienda en línea a través de un complemento que instalan).
la comunicación entre la tienda en línea y nuestra API se autentica mediante OAuth 2.0
Si queda un saldo en la tarjeta de regalo, se genera un nuevo código de tarjeta de regalo (al usuario se le envía un nuevo enlace para obtener su nuevo código de tarjeta de regalo para el saldo)
Cuando la tienda en línea nos está facturando, nos proporcionan una lista de las ID de pago, que luego comparamos con los códigos de las tarjetas de regalo en nuestro backend (y luego con nuestro emisor).

Protege:

El código de la tarjeta de regalo no se envía a un correo electrónico, solo el enlace (en nuestro backend podemos hacer algunos cheques, como la fecha de caducidad del pedido, si el crédito ya se ha agotado antes de mostrar el código de la tarjeta de regalo)
Alguien con acceso a la base de datos de la tienda en línea no verá nuestros códigos de tarjetas de regalo
Alguien que ha pirateado nuestra base de datos no puede ver los códigos de las tarjetas de regalo (ya que están recortados), ni generar el enlace para ver los códigos de las tarjetas de regalo (ya que la clave para el enlace está recortada)

Hazme saber si hay algún comentario.