Могут ли магазины использовать карточные платежи для отслеживания/профилирования клиентов?

Могут ли магазины использовать платежную информацию при оплате дебетовой или кредитной картой для отслеживания покупательских привычек покупателя?

Другими словами, может ли продавец связать разные покупки в разное время в своем магазине вместе, если они были совершены с помощью одной и той же карты или оплачены с одного и того же банковского счета?

Под «может» я подразумеваю как технически, так и юридически. Юридическая часть, конечно, зависит от юрисдикции и, возможно, от условий поставщика платежных услуг, поэтому, пожалуйста, включите это в свой ответ, где это уместно.

Я знаю, что банки отслеживают платежи, сделанные с помощью карты, мне интересно, могут ли это делать и магазины.

Технически это легкая часть. Юридически и договорно, кажется, есть некоторые ограничения. Насколько я понимаю, хотя я никогда не видел ничего авторитетного по этому вопросу, магазины могут соскребать имя карты, которое вместе с почтовым индексом, который они запрашивают (незаконно в Калифорнии), может быть сопоставлено для однозначной идентификации многих людей. Я слышал, но хотел бы официальное подтверждение, что магазины в США не могут очищать номер карты (даже если он затем хешируется или преобразуется) для любого другого использования, кроме текущей транзакции.
Я точно знаю, что это делается в Великобритании на регулярной основе, это одна из причин, по которой я склонен платить наличными.

Ответы (2)

Я точно знаю, что это происходит, поскольку я помогал внедрить такое решение для продавца, у которого есть несколько брендов.

Для того, над которым я работал, использовались не фактические номера кредитных карт, а токены, представляющие номера кредитных карт. Не вдаваясь в подробности безопасности, это был односторонний процесс . Номер кредитной карты клиента всегда приводил к одному и тому же токену, но пойти другим путем было практически невозможно. Даже если жетоны будут украдены, они будут бесполезны для воров.

Большинство компаний, внедряющих эти решения, заинтересованы только в таргетированном маркетинге. Например, сеть ресторанов может показать, что владелец данной кредитной карты заказывал вегетарианские блюда для большинства блюд. Было бы расточительством и, возможно, оскорбительным послать такому покупателю купон на 5 долларов на стейк-ужин.

Я бы также сказал, что большинство этих компаний заинтересованы в защите личности своих клиентов и будут использовать метод типа токена, даже если они не рискуют проблемами соответствия.

Пит, я добавил ссылку на односторонние функции. Надеюсь, ты не против. Именно так я бы реализовал что-то подобное. :)
Кстати, я заметил, что Home Depot, кажется, делает что-то подобное. Всякий раз, когда я покупаю что-то с помощью своей карты в Home Depot, он знает мой адрес электронной почты и спрашивает, хочу ли я получить квитанцию ​​по электронной почте. Если бы они не хранили мою карту (или хэш/токен от нее), у них не было бы возможности узнать, кто я такой, чтобы показать мне мой адрес электронной почты.
Наивное пространство поиска составляет 10 ^ 15 + 10 ^ 14 (если вы допускаете 15-значные номера карт, в основном AmEx; разница в 10% на самом деле не так уж велика), потому что последняя цифра всегда является контрольной цифрой. Примерно 2 ^ 50 пространства поиска, и, кроме того, легко выполнять пошаговый поиск. Не так сложно для решительного злоумышленника, если только вы не выполняете серьезные итерации хеширования.
@MichaelKjörling Вы забываете, что любой здравомыслящий человек, использующий хеш для номеров кредитных карт, также будет использовать соль? Таким образом, ваш расчет размера области поиска применяется к каждому токену, а не ко всем токенам. Более того, компании, заботящиеся о безопасности, вероятно, будут использовать какой-то алгоритм, такой как Bcrypt, который будет гораздо сложнее взломать, чем, например, MD5 или SHA1.
@ChrisCirefice, для тех, кто не является экспертом по безопасности, соленые Bcrypt и MD5 выглядят одинаково - обе они являются односторонними функциями.
Чтобы продолжить пример с Home Depot, если у вас нет чека, но есть кредитная карта, которую вы использовали для покупки товара, они могут найти запись о продажах.
@ChrisCirefice: цель соли - сделать невозможным определение совпадения двух паролей. Назначение описываемых токенов — определить, были ли совершены две транзакции с одной и той же картой. Как можно посолить токены, не сделав их бесполезными?
@supercat Вы не солите жетоны. Токены, насколько я понимаю, являются результатом хеширования. Вы бы использовали соль + номер карты. Таким образом, вы не сможете перебирать каждый номер карты через алгоритм хеширования, чтобы получить совпадающие хэши. Хэши не будут одинаковыми из-за соли. Но соль сохраняется, так что когда вы делаете соль + номер карты при следующей транзакции, генерируется тот же хэш.
@supercat: хотя ответ здесь говорит «защита личности своего клиента», он также говорит «целевой маркетинг», для которого вам нужны имя и адрес клиента. Поэтому я рискну и предположу, что вы можете использовать имя на кредитной карте для поиска (или случайного создания при первом использовании) соли, а затем использовать эту соль для хеширования номера карты в токен. Это будет означать, что на каждого клиента (имя) будет только одна соль вместо одной соли на карту, но это можно немного усовершенствовать. Я не специалист по соблюдению правил обработки кредитных карт, и мое мнение не следует воспринимать как совет ;-)
@SteveJessop «здесь также говорится «целевой маркетинг», для которого вам нужны имя и адрес клиента». Не обязательно. Мой обычный супермаркет распечатывает купоны на специальные предложения на кассе. Некоторые из них, очевидно, нацелены на историю покупок с течением времени, а не только на текущую корзину покупок.
@ChrisCirefice Что Марк сказал о соленом bcrypt и MD5. Кроме того, вам действительно нужен только один номер кредитной карты за раз...
@SteveJessop: я не рассматривал возможность объединения номера учетной записи с закодированным именем при создании хешированного токена, что увеличило бы пространство поиска достаточно, чтобы сделать обратное проектирование токенов непрактичным. Однако не уверен, как можно обращаться с людьми, которые меняют имя.
@supercat: если вы хэшируете имя и номер карты вместе, чтобы получить токен, и сбрасываете все с этого токена, то вы уже приняли, вы потеряете след и начнете с нуля всякий раз, когда номер карты меняется. Я бы не считал проблемой сделать то же самое при смене имени. В конце концов, это довольно случайное отслеживание, это не учетная запись, которую контролирует пользователь, и мы также не пытаемся предотвратить уклонение людей от нас (что они легко могут сделать, например, заплатив наличными, если они действительно этого хотят).
Используя всю доступную информацию на кредитной карте и хорошую функцию медленного хеширования, такую ​​как bcrypt или скрипт, должно быть очень сложно реверсировать такие хеш-токены, но, учитывая послужной список хранения паролей в компаниях, я бы не стал спорить, что многие компании делают это. криптографически правильная вещь в этом случае.

Была история магазина Target, который начал рассылать 16-17-летней девушке рекламу, ориентированную на беременную женщину. Отец расстроился и поговорил с управляющим местного магазина. В итоге она забеременела . Но все равно жуткая история. Они профилировали ее на основе покупок.

(См. комментарий Бена ниже со ссылкой на историю. Я довольно хорошо вспомнил этот анекдот.)

Вот статья журнала Time об этом ; в статье конкретно говорится, что Target использовала идентификационный номер, который они привязали к кредитной карте девушки, чтобы отслеживать ее покупки. В других статьях, посвященных той же истории , говорится то же самое.
Могут ли магазины использовать карточные платежи для отслеживания/профилирования клиентов?
СпросиСетьПолитика конфиденциальности1y, 0v