Понимание междоменной аутентификации пользователя

Question

Цель: Website1 отправляет данные пользователя Website2 через http-запросы.

Проблема: сайт2 гарантированно получил данные с сайта1, а не какой-то хакер.

ПРИМЕЧАНИЕ: я не буду использовать HTTPS, я понимаю, что это решит большую проблему, но сейчас GAE не поддерживает SSL для вашего собственного доменного имени: http://code.google.com/appengine/kb/general.html#httpsapps

Итак, я добился большого прогресса, шифруя и отправляя данные между двумя сайтами, а другой - сайт, способный дешифровать и читать данные. Я нахожусь на Google App Engine / Python / Django-nonreal, и эта страница была отличным ресурсом для того, чтобы заставить работать pycrypto: http://code.activestate.com/recipes/576980/ Kn

Так что мне удобно знать, что пользовательские данные зашифрованы и вам нужен ключ для их чтения, но как Website2 ЗНАЕТ, что запрос поступил с Website1? Что мешает хакеру снова отправить тот же самый запрос, и Website2 считает, что этот хакер действительно может делать что-то на Website2?

Например, не мог ли кто-нибудь просто прослушать http-запрос и записать, какие зашифрованные данные были отправлены через линию? И тогда хакер может сделать свой собственный запрос с теми же значениями, которые раньше использовал Website1, и хакер может сделать то же самое с Website2, что и Website1? По сути, хакер сказал бы Website2, что он является действительным зарегистрированным пользователем Website1.

Общая цель: Website2 сообщает пользовательские данные, которые поступают только из запросов от Website1. Любые другие запросы от хакера, который использует те же зашифрованные данные Website1, отправленные на Website2, не будут работать, если только ваш Website1.

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

Answer 1

Чтобы предотвратить повторные атаки, вам необходимо указать одноразовый номер и MAC (код аутентификации сообщения).

MAC может быть просто HMAC-SHA1 содержимого зашифрованного сообщения. Принимающая сторона вычислит тот же MAC и убедится, что он совпадает. Ключ для HMAC-SHA1 должен быть секретом, известным обеим сторонам. Этот шаг важен - просто потому, что ваши данные зашифрованы, не означает, что они не могут быть подделаны. В частности, если злоумышленник может изменить только одноразовый номер (см. Далее), у вас будут проблемы. Так что используйте правильный MAC.

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

Вы можете избежать необходимости хранить бесконечное количество одноразовых номеров, также прикрепив дату окончания срока действия к одноразовому номеру. Сообщения, полученные после истечения срока действия, должны быть отклонены. Одноразовые одноразовые номера могут быть удалены из базы данных видимых одноразовых номеров после истечения срока действия, а также нескольких часов для учета возможных разностей часов.

Генерация одноразового номера может быть сложно сделать правильно. Вот одна из техник:

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

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

Answer 2

Есть несколько способов сделать это:

Использование одноразовых номеров

Передать значение в зашифрованном сообщении, которое может встречаться только один раз

Проверка

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

Рукопожатие

Перед отправкой сообщения отправителю необходимо выполнить рукопожатие с использованием механизма ответа на запрос - файлы cookie используются для поддержания состояния отдельных запросов

и многие другие ..

Но если это для аутентификации, почему бы вам не использовать OpenID? Это решило все эти проблемы, и есть готовые библиотеки практически для всех платформ / фреймворков.