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

Question

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

Задача: Website2 гарантирует, что данные поступают с сайта 1, а не с каким-то хакером.

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

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

Итак, мне комфортно знать, что данные пользователя зашифрованы и что вам нужно иметь ключ, чтобы прочитать его, но как веб-сайт2 знал, что запрос пришел с сайта 1? Что мешает хакеру отправлять тот же запрос еще раз, и Website2 думает, что этот хакер действительно делает что-то на Website2?

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

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

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

Answer 1

Для предотвращения повторных атак вам необходимо включить nonce и MAC (Message Authentication Code).

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

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

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

Создание nonce может быть сложно сделать правильно. Вот один из способов:

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

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

Answer 2

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

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

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

Проверка

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

Рукопожатие

Как часть посылки сообщения, отправитель должен сделать рукопожатие с использованием механизма запроса-ответа перед тем, как проверка подлинности - куки используются для поддержания состояния между отдельными запросами

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

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