Как правильно зашифровать номер телефона на php приватным ключом и расшифровать на клиенте?

Question

[Vanya Huk]

Как правильно зашифровать номер телефона на php приватным ключом и расшифровать на клиенте?

пример - am.ru

Comments

[sim3x]

Зачем?

[Vanya Huk]

sim3x, чтобы номера телефонов клиентов сложнее было спарсить

[sim3x]

Vanya Huk, делайте их картинками

[Dmitry Bay]

Vanya Huk, а в чем проблема парсить с необходимым ключом ?

[Александр Аксентьев]

Авито например как парсили, так и парсят, несмотря на все эти скрывания номера и "нажмите чтобы увидеть номер".

Смысла вообще никакого в этом.

Это не end-to-end шифрование получится на выходе, если вы об этом думаете)

[Vanya Huk]

Dmitry Bay, нужно каким-то образом зашыфровать на сервере номет телефона, передать ключ клиенту тоже в зашыфрованном виде ( скорее всего base64 ) и написать на клиенте алгоритм для расшыфровки, а сам js минифоцыровать через webpack

[Vanya Huk]

Александр Аксентьев, пример сайта - am.ru

[Dmitry Bay]

Vanya Huk,

А что сложного то?
Берете библиотеку, реализованную на языке вашего бэка и фронта.
На бэке запускаете енкодер, на клиенте декодер.

Каждому клиенту выписываете персональный ключ, который хранится на фронте так же. И отдаете.

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

[Александр Аксентьев]

Vanya Huk,

нужно каким-то образом зашыфровать на сервере номет телефона, передать ключ клиенту тоже в зашыфрованном виде ( скорее всего base64 ) и написать на клиенте алгоритм для расшыфровки, а сам js минифоцыровать через webpack

и на выходе вы потратите N часов, а обход этой "защиты" дополнительный займёт N минут.

Просто скрывайте JSом полностью или частично + маскировка любая например арифметическая операция, так чтобы часть номера была в JS, и нельзя было достать просто посмотрев в код страницы(! не JS).
Посмотрев в JS всё равно можно будет достать номер, только это делать не так долго и упорото как шифрование через ключ. А профита так же, от совсем тупых скриптов спасёт, от целенаправленных не спасёт.

[Moskus]

Если вы также программируете, как пишете по-русски, у вас всё равно ничего не получится.

[Stalker_RED]

Александр Аксентьев,

Авито например как парсили, так и парсят, несмотря на все эти скрывания номера и "нажмите чтобы увидеть номер".

В большинстве случаев это сделано не для усложнения парсинга, а для подсчета просмотра номеров.
На клик по этим "нажмите для просмотра" вешают всякие следящие скрипты типа гугл-аналитики.

[Александр Аксентьев]

Stalker_RED, вполне логично) Но парсинг тоже не исключён)
Но с защитой от парсинга в авито слегка поехали уже. Получал бан айпишника за открытие ~10 объявлений подряд, когда что-то искал :D

[Vanya Huk]

Moskus, обіцяю вивчити російську, як тільки Ви підтягнете українську ;)

[Moskus]

Vanya Huk, это не раньше чем мне что-то понадобится на украинских форумах, что сильно сомнительно.

[Монти Пайтон]

Moskus, чому, ви що зовсiм анi буваєте наприклад у dou.ua чи ще десь iнде?

[Moskus]

Монти Пайтон, естественно, нет. Я вообще не в IT-индустрии работаю.

[Монти Пайтон]

Moskus, о це так, ти ба

[stratosmi]

Александр Аксентьев,

Авито например как парсили, так и парсят, несмотря на все эти скрывания номера и "нажмите чтобы увидеть номер".

Так то Авито.

[stratosmi]

Vanya Huk,

нужно каким-то образом зашыфровать на сервере номет телефона, передать ключ клиенту тоже в зашыфрованном виде ( скорее всего base64 ) и написать на клиенте алгоритм для расшыфровки, а сам js минифоцыровать через webpack

Парзеры притворяются браузерами, то есть клиентами.
Смысла в этом нет

[stratosmi]

Dmitry Bay,

Простой парсер можно написать на NodeJs, который будет эмулировать запросы настоящего клиента.

Тогда уж на специализированном PhantomJS или SlimerJS

[Dmitry Bay]

stratosmi, я привел пример, в котором достаточно знать только js.
Как раз phantomJs использовал длительное время для написания парсеров.

Answer 1

[xmoonlight]

Всё чуть сложнее, чем кажется.
1. Посли реги клиента мы определяем его клиентский идентификатор (CID; на основе браузера и подсети провайдера, к примеру)
2. Записывем его в базу на сервере и присылаем линк подтверждения регистрации на почту. Линк содержит криптованный клиентский ключ (серверным ключом, ключ для каждого клиента - генерируется свой).
3. После перехода по линку мы проверяем, что это действительно то устройство и наш пользователь, и присылаем ключ для дешифровки ключа и сохраняем его в браузер (Cookies или LocalStorage).
4. В момент загрузки закрытых данных (на сервере - они закрываются ключом авторизованного клиента), через JS мы берём ключ из хранилища браузера и дешифруем: пользователь видит чистые текстовые данные.

На любые "закрытые" данные нужно иметь всегда 2 ключа на их чтение: пользовательский и публичный.

Пользовательский - когда юзер залогинен.
Публичный - для всех, кто не залогинен. Он обычно НЕ используется, но если захотите какие-то данные открыть позже - нужно это предусмотреть заранее!

Как-то так...

Comments

[Виктор Дидицкий]

После перехода по линку мы проверяем, что это действительно то устройство и наш пользователь, и присылаем ключ для дешифровки ключа и сохраняем его в браузер (Cookies или LocalStorage).

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

Вопрос лишь в том, как получить чужую активационную ссылку.

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

[xmoonlight]

Виктор Дидицкий, читайте ответ внимательнее, п.3:

3. После перехода по линку мы проверяем, что это действительно то устройство и наш пользователь

Клиентский идентификатор и временный токен из куков - тоже получите также, как и доступ к почте?)

[Виктор Дидицкий]

Клиентский идентификатор и временный токен необходимо получить 1 раз, когда зарегистрируешься. Далее проходите по ссылки и получаете ключ для расшифровки системного ключа. А он то, как я понял общий для всех.

Далее имея системный ключ и любую активационную ссылку можно получить любой пользовательский ключ.

[xmoonlight]

Виктор Дидицкий, либо я что-то не понимаю, либо - Вы. Давайте разберёмся...
Вот я пишу:

Линк содержит криптованный клиентский ключ (серверным ключом, ключ для каждого клиента - генерируется свой)

Вы про этот этап говорите?

[Виктор Дидицкий]

xmoonlight , да. Имея серверный ключ, который получили зарегистрировавшись ранее, можно достать из любой ссылки клиентский ключ

[xmoonlight]

Виктор Дидицкий, Серверный ключ уникален для каждого CID и находится на сервере.
Либо я не до конца понимаю...

[Виктор Дидицкий]

Линк содержит криптованный клиентский ключ (серверным ключом, ключ для каждого клиента - генерируется свой)

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

Видимо я ошибся

[xmoonlight]

Виктор Дидицкий, конечно же, серверный - уникальный тоже для каждого пользователя.

Answer 2

[Xveeder]

Такая защита на раз обходится headless-браузерами или тем же Selenium, через которые страница будет рендериться.

Ограничение на парсинг, регинг, постинг и т.д. работает только в виде увеличения стоимости сихьдействий, а именно:

1. Капчи на возврат данных. Даже простые капчи заставляют парсеры отправлять их в специальные сервисы, которые сильно увеличивают стоимость процесса.

2. Ограничения парсинга по ip. Прокси-сервера стоят по 50-100 рублей за штуку. И если боту придется менять прокси каждые 100 запрсов. Юзер 100 раз подумает, а стоит ли парсить или нет.

Comments

[Dmitry Bay]

1) вроде бы цены копеечные на простые капчи.
2) так можно и во всем городе свет выключить. не все клиенты до сих пор на белых IP. Сейчас гляну на сервисе плати - есть предложения по прокси - 1000 руб за 1000 ip на 10 дней.
даже гипотетические 50 запросов на 1 ip - дает 50К записей. Если 50 запросов ограничение на один день, то за эти 10 дней можно выгрузить всю базу номеров. И продать ее пару раз и окупить затраты на прокси.

[Xveeder]

Dmitry Bay, 50 рублей за 1 000 каптч. Эти прокси юзают по 500 человек. Они:

1) Медленные
2) Палятся

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

Answer 3

[ixon]

Можно использовать эту имплементацию RSA для PHP:
phpseclib.sourceforge.net

<?php
include('Crypt/RSA.php');

$privatekey = file_get_contents('private.key');

$rsa = new Crypt_RSA();
$rsa->loadKey($privatekey);

$plaintext = new Math_BigInteger('[phone]');
echo $rsa->_exponentiate($plaintext)->toBytes();
?>