¿Pueden las tiendas usar pagos con tarjeta para rastrear/perfilar a los clientes?

¿Pueden las tiendas usar la información de pago cuando paga con una tarjeta de débito o crédito para rastrear los hábitos de compra de un cliente?

En otras palabras, ¿puede un comerciante vincular diferentes compras en diferentes momentos en su tienda si se realizaron con la misma tarjeta o se pagaron desde la misma cuenta bancaria?

Por 'puede' me refiero tanto técnica como legalmente. La parte legal, por supuesto, depende de la jurisdicción y quizás de los términos del proveedor de pago, así que inclúyalo en su respuesta cuando sea relevante.

Sé que los bancos rastrean los pagos que se realizan con una tarjeta, me pregunto si las tiendas también pueden hacerlo.

Técnicamente es la parte fácil. Legal y contractualmente, parece haber alguna restricción. Según tengo entendido, aunque nunca he visto nada autoritario sobre el tema, las tiendas pueden raspar el nombre de la tarjeta, que, junto con el código postal que solicitan (ilegal en California), se puede correlacionar para identificar de manera única a muchas personas. Escuché, pero me gustaría una confirmación autorizada, que las tiendas de EE. UU. no pueden raspar el número de tarjeta (incluso si luego se codifica o transforma) para ningún otro uso que no sea la transacción en cuestión.
Sé con certeza que esto se hace en el Reino Unido de manera regular, es una de las razones por las que tiendo a pagar en efectivo.

Respuestas (2)

Sé con certeza que esto está sucediendo porque ayudé a implementar una solución de este tipo para un comerciante que tiene varias marcas.

Para el que trabajé, no se usaron números de tarjetas de crédito reales, sino tokens que representan números de tarjetas de crédito. Sin entrar en demasiadas cosas de seguridad, era una cosa de una sola dirección . El número de tarjeta de crédito de un cliente siempre daría como resultado el mismo token, pero ir en sentido contrario era prácticamente imposible. Incluso si las fichas fueran robadas, serían inútiles para los ladrones.

La mayoría de las empresas que implementan estas soluciones solo están interesadas en marketing dirigido. Por ejemplo, una cadena de restaurantes podría mostrar que el propietario de una determinada tarjeta de crédito ordenó opciones vegetarianas para la mayoría de las comidas. Sería un desperdicio, y tal vez ofensivo, enviar a ese cliente un cupón de $5 de descuento en una cena de bistec.

También diría que la mayoría de estas empresas están interesadas en proteger la identidad de sus clientes y utilizarían un método de tipo token incluso si no se arriesgaran a tener problemas de cumplimiento.

Pete, agregué un enlace a las funciones unidireccionales. Espero que no te moleste. Es exactamente cómo habría implementado algo como esto. :)
Ancedotally, he notado que Home Depot parece hacer algo como esto. Cada vez que compro algo con mi tarjeta en Home Depot, conoce mi dirección de correo electrónico y me pregunta si quiero un recibo por correo electrónico. A menos que estuvieran almacenando mi tarjeta (o un hash/token de ella), no tendrían forma de saber quién era para mostrarme mi dirección de correo electrónico.
El espacio de búsqueda ingenuo es 10 ^ 15 + 10 ^ 14 (si permite números de tarjeta de 15 dígitos, principalmente AmEx; sin embargo, la diferencia del 10% en realidad no es tan grande), porque el último dígito siempre es un dígito de control. Alrededor de un espacio de búsqueda de 2^50 y, además, fácil de buscar de forma incremental. No es tan difícil para un atacante determinado a menos que esté haciendo algunas iteraciones de hash serias.
@MichaelKjörling ¿Estás olvidando que cualquier persona en su sano juicio que use un hash en los números de tarjetas de crédito también estaría usando una sal? Por lo tanto, su cálculo del tamaño del espacio de búsqueda se aplica a cada token, no a todos los tokens. Además, las empresas que se preocupan por la seguridad probablemente utilizarán algún algoritmo como Bcrypt, que sería mucho más difícil de aplicar por fuerza bruta que MD5 o SHA1, por ejemplo.
@ChrisCirefice, para cualquiera que no sea un experto en seguridad, Bcrypt salado y MD5 tienen el mismo aspecto: ambos son funciones unidireccionales.
Para continuar con el ejemplo de Home Depot, si no tiene un recibo, pero tiene la tarjeta de crédito que utilizó para comprar el artículo, pueden buscar el registro de ventas.
@ChrisCirefice: El propósito de salt es hacer que sea imposible determinar si dos contraseñas coinciden. El propósito de los tokens descritos es determinar si se realizaron dos transacciones con la misma tarjeta. ¿Cómo se podría salar las fichas sin hacerlas inútiles?
@supercat No sala las fichas. Los tokens, a mi entender, son el resultado del hash. Usarías sal + el número de tarjeta. De esta manera, no podría iterar cada número de tarjeta a través del algoritmo hash para obtener hashes coincidentes. Los hachís no serían los mismos, debido a la sal. Pero la sal se almacena, de modo que cuando haces sal + número de tarjeta en la próxima transacción, se genera el mismo hash.
@supercat: aunque la respuesta aquí dice "proteger la identidad de sus clientes", también dice "marketing dirigido", para lo cual necesita el nombre y la dirección del cliente. Así que me arriesgaré y supondré que podría usar el nombre en la tarjeta de crédito para buscar (o generar aleatoriamente en el primer uso) una sal, luego usar esa sal para convertir el número de tarjeta en un token. Significaría que solo hay una sal por cliente (nombre) en lugar de una sal por tarjeta, pero eso podría mejorarse un poco. No soy un oficial de cumplimiento de procesamiento de tarjetas de crédito y mi opinión no debe tomarse como un consejo ;-)
@SteveJessop "también dice" marketing dirigido ", para lo cual necesita el nombre y la dirección del cliente". No necesariamente. Mi supermercado habitual imprime cupones para ofertas especiales en las cajas registradoras. Algunos de ellos obviamente están dirigidos al historial de compras de uno a lo largo del tiempo, no solo en función de la cesta de la compra actual.
@ChrisCirefice Lo que dijo Mark sobre bcrypt salado y MD5. Además, solo necesitas un número de tarjeta de crédito a la vez...
@SteveJessop: No había considerado la posibilidad de combinar el número de cuenta con el nombre codificado para producir un token con hash, lo que aumentaría el espacio de búsqueda lo suficiente como para hacer que la ingeniería inversa de los tokens no sea práctica. Sin embargo, no estoy seguro de cómo se manejaría a las personas que cambian de nombre.
@supercat: si está combinando el nombre y el número de la tarjeta para obtener un token, y está eliminando todo ese token, entonces ya ha aceptado que perderá la pista y comenzará desde cero cada vez que cambie el número de la tarjeta. No consideraría un problema hacer lo mismo cuando cambia el nombre. Después de todo, este es un seguimiento bastante casual, no es una cuenta que controle el usuario y tampoco estamos tratando de evitar que las personas nos eludan (lo que pueden hacer fácilmente, por ejemplo, pagando en efectivo, si realmente les interesa).
Usando toda la información disponible en una tarjeta de crédito y una buena función de hashing lento como bcrypt o script, debería ser muy difícil revertir tales tokens hash, pero dado el historial de almacenamiento de contraseñas en las empresas, no apostaría que muchas empresas lo están haciendo. lo criptográficamente correcto en este caso.

Hubo una historia de una tienda, Target, que comenzó a enviar anuncios dirigidos a una mujer embarazada a una niña de 16-17 años. El padre se molestó y habló con el gerente de la tienda local. Al final, ella estaba embarazada. Pero aún así, escalofriante historia. La perfilaron en base a las compras.

(Vea el comentario de Ben a continuación, con un enlace a la historia. Recordé la anécdota bastante bien).

Aquí hay un artículo de la revista Time al respecto ; el artículo dice específicamente que Target usó un número de identificación que vincularon a la tarjeta de crédito de la niña para rastrear sus compras. Otros artículos que cubren la misma historia dicen cosas similares.