ilyak, Максим, хочу внести ясность по поводу дешифровки хэша. То что, я сформулировал по поводу математической невозможности восстановления хэш функции — верно. Однако Вы показываете на примере как за счёт низкой разрядности входных данных и ограниченного набора символов во входном потоке вы можете подобрать хэш. Данный метод никак не компрометирует алгоритм хэша, а основан всего лишь на вашем знании (или предположении о знании) того как записан номер телефона. если перед ним будет указан какой-либо префикс, возможно динамический навроде даты рождения, то задача у вас усложнится. А если вместо телефона будет email? Еще сложнее. Смысл написанного был в том как показать на примере двух компаний каждая из которых имеет свой набор данных по своим клиентам можно передать данные не являющиеся персональными от одной компании к другой и этих данных будет достаточно для связывания профилей клиентов в базах двух компаний.
Если подробнее разобрать данный кейс, то проблемы с передачей персональных данных (ПД) не возникает. Схема может работать таким образом:
1) макдак при покупке у него интересующего продукта и оплате по карте отправляет в сбер сообщение содержащее всего 2 числа: точное время и сумму чека. Думаю, что макдак даже не имеет доступа к фио владельца карты. Предполагаю, что касса печает в чеке делает банковский терминал напрямую. Да и Фио им не нужно, потому что, см. ниже
2) Банк по своей выписке находит кто из его клиентов совершил транзакцию в указанное время на указанную сумму которая прошла через терминал макдака. Вероятность сопоставления транзакций по таким данным близка к 100%.
И так, первый этап пройден без раскрытия ПД. Теперь банк знает клиента который приобрёл заказанный товар.
3) Далее, банк найдя этого клиента,должен как-то маякнуть своему партнеру о том что ему нужно показать рекламу. Как это сделать без передачи ПД? Просто: банк использует номер телефона клиента, который ему известен в качестве идентификатора. Вычисляет одностороннюю хэш функцию по нему, получается некая зашифрованная строка. Расшифровать её невозможно математически.
На стороне партнера имеется своя база клиентов, например все клиенты вконтакта. Что он знает о них? — как минимум номер телефона. Что ему нужно сделать? — вычислить хэш по такому же алгоритму, что и делает банк. Далее, когда к нему из банка приходит сообщение с зашифрованной строкой-хэшем, то он просто находит точно такой же хэш пробегая по своей базе и получает по нему полный профиль клиента из своей базы. Всё, сопоставление клиента выполнено, передачи ПД не было.
Получается, что официальный ответ банка отчасти правда. Они действительно могут закодировать часть ПД (н-р номер телефона, а это может быть и ФИО, что именно — не так важно) и передавать в закодированном виде, при чём математически гарантируется, что восстановить исходные данные невозможно.
Дальше клиенту показывается реклама, конверсия считается аналогичным способом.
Как с этим можно бороться? Платить налом и использовать noscript/adblock+.
Дискуссии пользователя
ilyak, Максим, хочу внести ясность по поводу дешифровки хэша. То что, я сформулировал по поводу математической невозможности восстановления хэш функции — верно. Однако Вы показываете на примере как за счёт низкой разрядности входных данных и ограниченного набора символов во входном потоке вы можете подобрать хэш. Данный метод никак не компрометирует алгоритм хэша, а основан всего лишь на вашем знании (или предположении о знании) того как записан номер телефона. если перед ним будет указан какой-либо префикс, возможно динамический навроде даты рождения, то задача у вас усложнится. А если вместо телефона будет email? Еще сложнее. Смысл написанного был в том как показать на примере двух компаний каждая из которых имеет свой набор данных по своим клиентам можно передать данные не являющиеся персональными от одной компании к другой и этих данных будет достаточно для связывания профилей клиентов в базах двух компаний.
Если подробнее разобрать данный кейс, то проблемы с передачей персональных данных (ПД) не возникает. Схема может работать таким образом:
1) макдак при покупке у него интересующего продукта и оплате по карте отправляет в сбер сообщение содержащее всего 2 числа: точное время и сумму чека. Думаю, что макдак даже не имеет доступа к фио владельца карты. Предполагаю, что касса печает в чеке делает банковский терминал напрямую. Да и Фио им не нужно, потому что, см. ниже
2) Банк по своей выписке находит кто из его клиентов совершил транзакцию в указанное время на указанную сумму которая прошла через терминал макдака. Вероятность сопоставления транзакций по таким данным близка к 100%.
И так, первый этап пройден без раскрытия ПД. Теперь банк знает клиента который приобрёл заказанный товар.
3) Далее, банк найдя этого клиента,должен как-то маякнуть своему партнеру о том что ему нужно показать рекламу. Как это сделать без передачи ПД? Просто: банк использует номер телефона клиента, который ему известен в качестве идентификатора. Вычисляет одностороннюю хэш функцию по нему, получается некая зашифрованная строка. Расшифровать её невозможно математически.
На стороне партнера имеется своя база клиентов, например все клиенты вконтакта. Что он знает о них? — как минимум номер телефона. Что ему нужно сделать? — вычислить хэш по такому же алгоритму, что и делает банк. Далее, когда к нему из банка приходит сообщение с зашифрованной строкой-хэшем, то он просто находит точно такой же хэш пробегая по своей базе и получает по нему полный профиль клиента из своей базы. Всё, сопоставление клиента выполнено, передачи ПД не было.
Получается, что официальный ответ банка отчасти правда. Они действительно могут закодировать часть ПД (н-р номер телефона, а это может быть и ФИО, что именно — не так важно) и передавать в закодированном виде, при чём математически гарантируется, что восстановить исходные данные невозможно.
Дальше клиенту показывается реклама, конверсия считается аналогичным способом.
Как с этим можно бороться? Платить налом и использовать noscript/adblock+.