Безопасная междоменная идентификационная форма

Question

У меня есть сервер «A». У вас есть сервер «B». Сервер «A» хочет предоставить форму входа на сервер «B» (имя пользователя и пароль).

Как реализовать этот сценарий, когда сервер «B» не может видеть/перехватывать содержимое, заполненное пользователем? Учетные данные должны поступать безопасным образом на сервере «A» без перехвата.

Возможно ли это?

Вот лучший пример:

Сервер предлагает услуги по серверу B и сервер B предлагают услуги на пользователя, который имеет пароль в сервер . В какой-то момент пользователь должен пройти аутентификацию на сервере A, но форма входа будет отображаться на странице сервера. Я чист? И сервер B не может прочитать эти учетные данные.

бизнес логика сервер имеет много клиентов и сервер позволит третьим сторонам разрабатывать приложения для сервера A клиентов. Кто владеет основным паролем, является сервер A и сервер B не могут получить доступ/прочитать/перехватить эти учетные данные. То, как клиенты будут проходить проверку подлинности на сервере B является формой входа, встроенного в сервер B (я не могу перенаправить пользователя на сервер . Пользователь должен остаться на B странице сервера.).

Вопросов:

Что такое лучший способ встроить форму в сервер B?

Может ли сервер B запустить JavaScript, который сможет читать учетные данные пользователя перед отправкой?

Answer 1

С вашего вопроса кажется, что вы пытаетесь передать конфиденциальные данные через сервер B, но B не является конечным пунктом назначения. Даже если B является пунктом назначения (или источником), ответ по-прежнему тот же

Способ использования HTTPS/TLS/SSL. Это зашифрует данные с помощью открытого сертификата A, так что данные могут быть дешифрованы только закрытым ключом A, который имеет только A.

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

EDIT:

Чтобы сделать это, имея B служат страницам, но не быть в состоянии прочитать это данные, которые веб-страница обслуживается B шифровать данные с помощью Javascript на стороне клиента, с открытым ключом (в который может быть включен в страницу B). Хотя B имеет открытый ключ A, он не сможет расшифровать данные, зашифрованные JS. Он может только передать его на А.

EDIT:

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

* Это, конечно, предполагает пару ключей RSA с достаточной энтропией и длиной, чтобы считаться безопасным. Минимум 1024 бит, предпочтительно 2048 бит.

Еще один (и последний) EDIT: 09-May-2013

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

В моих предыдущих сообщениях я сделал существенное предположение, и серверу B доверено не совершать вредоносные попытки сбора учетных данных пользователя. Я сделал это предположение, потому что, как упоминалось в комментариях к halfer, очень неразумно и небезопасно позволять B собирать учетные данные пользователя, если B в первую очередь имеет ограниченную надежность. Кроме того, я сделал это предположение, потому что общая задача заключается в том, чтобы использовать третьи стороны для размещения вашего веб-приложения, такого как Heroku, Amazon и т. Д., Которые не были бы злонамеренными (они потеряли бы массу бизнеса, если бы они это сделали, и они вам нечего выиграть. Кроме того, у вас есть кто-то, кто будет привлекать к ответственности, если вы обнаружите нарушения безопасности. Таким образом, им может быть доверено, или вы не будете их использовать в первую очередь). Теперь я предполагаю, что вы - , а не, используя сторонний источник, подобный им, поскольку кажется очевидным, что это так.

Если B потенциально может быть вредоносным, то независимо от того, что вы делаете со своим кодом на стороне клиента, B может изменить его и перехватить учетные данные. До тех пор, пока B можно доверять, чтобы не изменять код на стороне клиента, мое предыдущее предложение будет работать. Однако, учитывая эту новую информацию о том, что B имеет ограниченную достоверность, было бы неразумно реализовывать мое предыдущее предложение.

Аутентификация пользователя вашим сервисом через ненадежную третью сторону является очень опасным делом, о чем свидетельствует сумма денег, которую PayPal потратила на создание API. Однако, если вы должны это сделать, вам нужно быть очень осторожным и рассмотреть возможность внедрения a solution similar to PayPal.

Если вам нужно пройти через третье лицо, то решение, аналогичное тому, что @halfer упоминает в комментарии выше, это путь, IMO.

[P] erhaps вы должны нажать на что-то в B, он перенаправляет А, получает разрешение пользователей с вашего сайта, и перенаправляет обратно к B с маркером аутентификации. Это имеет то преимущество, что вам не нравится пользователю ввести свой основной пароль на сайте, который не должен абсолютно доверять.

Есть пользователь перенаправляется на ваш сайт с помощью HTTPS/TLS/SSL.Это защищает учетные данные пользователя, а также проверяет вашу личность на пользователя, поэтому они с меньшей вероятностью попадают на фарминг-атаку. Затем вы можете предоставить достаточно случайный токен третьей стороне для использования в качестве аутентификации.

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

Если B не доверяется, тогда мой профессиональный совет не делает этого.