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

Question

[deffect]

Здравствуйте.
Вопрос, на мой вхгляд, очень простой. Но чего-то мне не хватает — ответить на него самостоятельно.

Дано: мой сервис раздаёт зарегистрированным в сервисе сайтам виджет (iframe). Для этого на сайте необходимо разместить iframe. Чтбы иметь возможность индефицировать сайт и определить, зарегестрирован он в моём сервисе или нет, iframe содержит id конкретного зарегестрированного сайта.
Но передавать «голый» id не хочется.

Вопрос: как мне зашифровать id так, чтобы получив этот закодированный id я смог бы его расшифровать и получить id. Нужно ли пользоваться какой-то хитрой функцией для этого или всё много проще?

Answer 1

[Алексей]

Переведите в base64 например.
Воспользуйтесь "хитрой функцией".
Храните в базе ключи id = хеш.
Любой вариант подойдет.

Answer 2

[Андрей]

Вы описываете задачу аутентификации посредством одного сообщения без раскрытия ключа.
(Иначе любой подсмотревший передаваемое другим сайтом значение - не важно голое или зашифрованное - просто его повторит в своем фрейме и будет авторизован ("replay attack")).

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

Чаще всего шифруют либо текущее время с какой-либо долей погрешности (например, минута или 30 секунд) либо постоянно увеличивающийся счетчик (что сложнее реализовывать, поскольку его приходится поддерживать и на серверной и на клиентской стороне).

На этом принципе работают банковские OTP-токены.

Comments

[betal]

Можно еще к клиенту привязать, к IP например. К счетчикам не стал бы, их нужно синхронизировать. С временем проще.

Answer 3

[BasilioCat]

По-моему вам просто надо сравнивать referer запросов с зарегистрированными доменными именами сайтов в вашем сервисе. Никто не мешает скопировать зашифрованный id и вставить его на другой сайт с таким же успехом. "Вызов" урла фрейма все равно инициируют обычные пользователи из браузера, заниматься подлогом реферера им нет резона. Для тех параноиков, у которых отключена передача реферера - просто не блокируйте виджет при пустом реферере.

Для подтверждения неизменности урла в абстрактном случае же лучше использовать подпись - например url?id=123&hash=123456789abcdef, где hash=md5($id.$secret_key);
Возможностью проверки таких подписей обладает даже nginx

Comments

[Андрей]

При такой формуле расчета хеша, что мешает скопировать id и готовый hash с другого сайта и отправить их, не расшифровывая.

[BasilioCat]

В данном конкретном случае это бесполезная схема. Но мало ли кому в другом случае пригодится

Answer 4

[Анатолий]

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

Answer 5

[afiskon]

Берем id. Считаем его hash, например, md5. Для краткости можно половину обрезать. Берем секретный ключ из конфига. Шифруем AES(key, "hash|id"). Это зашифрованный id. Вместо AES можно выбрать другой блочный (не потоковый!) шифр.

При передаче зашифрованного id зашифровываем его с помощью секретного ключа - unAES(key, secret_id). Разбиваем на hash|id. Если не разбивается - получили фигню, бросаем исключение. Считаем md5(id), если получили hash - значит все ОК, если нет - пришла фигня, бросаем исключение.

Comments

[Андрей]

Еще раз повторюсь (отвечал ранее для другой схемы) : что мешает в Вашей схеме скопировать id и готовый зашифрованный с другого сайта и отправить их, не расшифровывая ?

Answer 6

[Nadz Goldman]

Хабр радует.
Просто разложите по байтам, скомпонуйте и отдайте.
Вы знакомы с short-url?
Типа goo.gl/OkoJ67d
OkoJ67 - очень образно говоря - это побайтово сложенная data, которая в разложенном виде имееет нечто виде windows.com