Безопасна ли эта реализация единого входа?

Question

Клиент попросил нас разработать простое решение для единой регистрации для своих поставщиков.В этой ситуации у клиента есть много поставщиков с возможностями реализовать простое решение, которое позволяет пользователям поставщиков входить на сайт нашего клиента.Я придумал это:

Общие данные

Следующие данные будут переданы нам и указанному поставщику.

• user_id - Предоставлено поставщиком
• vendor_id - Предоставлено нами
• vendor_secret - Предоставлено нами.«Случайный» хэш SHA512

Функция общего хеширования

Наша спецификация будет определять следующую практику для создания ключа, который подходит для передачи через URLпараметры:

// Pseudo-code. Assume sha512() is a function in their native language that accepts a string and returns a SHA-512 hash
vendor_id = 341;
vendor_secret = "areallylonghash...";
user_id = "12345abcdef;&";
hash = sha512(vendor_id + ":" + vendor_secret + ":" + user_id);

SSO Process

1. Пользователь нажимает кнопку «войти» на сайте поставщика, и в точку входа SSO поставщика выдается запрос GET.
2. Поставщик получает запрос на точку входа (например, www.avendor.com/sign_in).
3. Поставщик использует вышеуказанную функцию хеширования для генерации хеша для пользователя.
4. Продавец перенаправляет наконечная точка нашего клиента с параметрами vendor_id, user_id и hash.
5. Мы получаем запрос в нашей конечной точке.Мы ищем vendor_secret из переданного vendor_id и пытаемся воссоздать hash, которое было отправлено нам.
6. Если сгенерированный хеш совпадает, создайте сеанс на сайте клиента.

Потенциальные проблемы

Если мы используем запрос GET для шага 4 перенаправления, возможно ли, что сгенерированный хеш может оказаться в истории браузера пользователя?Не очень безопасно, если кто-то может просто нажать на ссылку в истории.Можем ли мы использовать HTTP-заголовки для передачи хэша при перенаправлении?

Если вы дошли до этого места, спасибо.Все отзывы приветствуются!Мы хотим убедиться, что мы внедряем безопасное решение.

Answer 1

Ответ: нет, это не безопасно.

На шаге 4 пользовательский агент получает доступ к vendor_id, user_id и hash.Теперь клиент может добавить любую строку, которую он хочет, к user_id и изменить hash для соответствия.Я не уверен, что полностью понимаю ваше предложение, но похоже, что это может позволить одному пользователю войти в систему как другой пользователь, чье имя пользователя является префиксом его собственного.

Вам необходимо использовать HMAC вместо простого хэша.

Держитесь подальше от реализации своего собственного крипто!

Answer 2

3 (b) Поставщик отправляет API-запрос в ваше приложение с сгенерированным токеном

3 (c) Ваше приложение сохраняет токен с user_id

4 () Продавец перенаправляет с помощью параметров user_id, vendor_id, токен, хэш

Если токен совпадает с токеном из API, войдите в систему пользователя, удалите токен

Тогда URL-адрес перенаправления используется один раз

ИЛИ

Не делайте дополнительного запроса API.Используйте основанный на времени вращающийся ключ RSA.Тогда URL перенаправления работает только в течение 5 секунд или чего-то еще.