Что такое простой и безопасный способ передачи ключа входа с одного сайта на другой при перенаправлении пользователя?

Question

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

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

Моя первая мысль - передать идентификатор пользователя, зашифрованный как переменную post или значение строки запроса. Используя какой-то сценарий с открытым/закрытым ключом и добавив штамп DateTime к ключу, чтобы он менялся каждый раз.

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

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

Может ли кто-нибудь дать способ сделать это или посоветовать? Или это плохая идея?

Спасибо за ваше время.

Answer 1

В принципе, вы запрашиваете одноразовое решение. То, что вы описали звучит много как SAML, хотя SAML немного более продвинутый ;-)

Answer 2

Это зависит от того, насколько безопасно вы хотите, чтобы вся эта вещь была. Генерация зашифрованного токена со встроенной меткой времени все же оставляет вас открытой для подмены - если кто-то крадет токен (т. Е. Через сетевое обнюхивание), он сможет отправить свой запрос с украденным токеном. В зависимости от времени жизни вы дадите свой токен, на этот раз можно ограничить, но определенный хакер сможет это сделать. Кроме того, вы не можете сделать время, чтобы жить до малого - вы будете отклонять действительные запросы. Другой подход - генерировать токены «использовать один раз». Это «пуленепробиваемый» с точки зрения спуфинга, но для этого требуется координация между всеми серверами фермы серверов, обслуживающих ваше приложение, чтобы, если один из них обработал токен, другие отклонили бы его. Чтобы сделать его действительно безопасным для сценариев перехода на другой ресурс и т. Д., Для этого потребуются дополнительные шаги, поэтому все это сводится к тому, насколько безопасно это вам нужно, и сколько вы хотите инвестировать в его создание.

Answer 3

Я предлагаю смотреть на SAML

Answer 4

PGP будет работать, но он может получить медленно на сайте высокого трафика

Одна вещь, которую я делал в прошлом, используется совместно используемым секретным методом. Некоторый токен, который только я и другой оператор веб-сайта знает, связанный с чем-то, идентифицирующим пользователя (например, имя пользователя), а затем хэш с алгоритмом контрольной суммы, таким как SHA256 (вы можете использовать MD5 или SHA1, которые обычно более доступны, но они много легче сломать)

Другой конец должен делать то же, что и выше. Возьмите переданную идентификационную информацию и проверите ее. Сравните это с пройденной контрольной суммой, если они совпадают с логином.

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

Answer 5

В общем, ответ находится где-то в SHA256/MD5/SHA1 плюс общий секрет, основанный на человеке, на самом деле должен думать. Если есть деньги где-то, мы можем предположить, что нет никаких ограничений на то, что некоторые люди сделают - я бежал с [человеком] в Высшей школе в течение нескольких месяцев, чтобы наблюдать за тем, что эти люди будут делать на практике. Через несколько месяцев я научился не бегать с такими людьми. Утомленно избегая работы, внезапно в 4 часа ночи в субботу утром уровень усилий и аналитического функционирования можно было назвать только «Экспертиза» (примечание капитализации). Должно быть решение других сайтов, таких как Google, и у этого не будет шансов одуванчик в молнии.

Существует исследование в математических работах криптографии, в соответствии с которыми учреждение (с уважаемыми целями) может выдавать информацию - цифровые деньги - которые могут существовать на открытом проводе, но не раскрывают никакой информации. Кто их сломает? Мой опыт работы с [person] показывает, что это исследование в области социализации, зависит от того, с кем вы хотите работать. Какая защита от снифферов, если код уже доступен более просто, используя браузер?

<form type="hidden" value="myreallysecretid"> 

визави

<form type="hidden" value="weoi938389wiwdfu0789we394"> 

Так какой из них ценен от нападения? Кроме того, если кто-то хочет заманить у вас змеиное масло, возможно, вы получите телефонный звонок 2:59, который начинается: «Я инвестор, мы потопили тысячи на ваш сайт. Мне просто позвонил наш специалист по безопасности. .... «все, что вы можете сделать, чтобы подготовиться к этому моменту, - это использование установленных, известных инструментов, таких как SHA, из которых 256 разновидностей являются признанными« следующей вещью »- и имеют следовые элементы управления, которые защитник может использовать для страхования и склеивание.

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

Тогда вы не получите код.