Для тех Проверяющих сторон (RP), которые позволяют пользователю указывать поставщика OpenID (OP), мне кажется, что любой, кто знает или предполагает, что ваш OpenID может
RP "может" принять меры для предотвращения этого, разрешив только проверку OpenID исходным OP, но ...
OpenID - одна из тех систем, где вы должны доверять конечным точкам. Если RP не заслуживает доверия, тогда этот вид ассоциация отравления вполне возможно. Если RP действительно заслуживает доверия, то такая атака НАМНОГО сложнее. Чтобы избежать этой атаки, нужно использовать принцип локальной безопасности (в ServerFault это будет представление вашего имени пользователя во внутренней базе данных) с внешней конечной точкой OpenID (URL-адрес OpenID, ServerFault позволяет связать несколько из этих).
Вы по-прежнему можете атаковать с помощью атаки с отравлением DNS со стороны RP, например, * .livejournal.com будет перенаправлен на OP, который вы специально создали для атаки. Но это атака с отравлением DNS, а не ошибка самого OpenID. OpenID просто уязвим для создания DNS.
Я думаю, вы путаете OpenID и другие части User Security. Ваш OP - это механизм аутентификации, а не ваша учетная запись. Здесь, на ServerFault, у вас есть учетная запись. Эта учетная запись не имеет средств аутентификации сама по себе; за исключением того, что вы указываете это на один или несколько OP.
Когда вы пытаетесь войти в свою учетную запись здесь как SF, он просит ваш OP выполнить аутентификацию. Только этот один OP (или несколько OP, независимо от того, настроен он у вас) может аутентифицировать вас для целей вашей учетной записи SF.
Типичная система входа в систему (называемая тройной «А» или просто «AAA») состоит из трех частей:
Вы можете узнать больше о Системы AAA в Википедии.
Дэвид, ваше предположение неверно. OpenID работает следующим образом: 1) вы хотите войти на сайт relyingparty.com 2) вы указываете relyingparty.com свой OpenID, например david.com 3) relyingparty.com проверяет david.com (эй, это URL-адрес) для так называемой конечной точки OpenID, которую можно найти на david.com, но с помощью делегирования также в другом месте, например yahoo.com или google.com. назовем его davidsopenidprovider.com 4) Теперь вы перенаправлены на davidsopenidprovider.com. Работа davidsopenidprovider.com - аутентифицировать вас. Вам необходимо войти на сайт davidsopenidprovider.com. Как работает этот логин, решать davidsopenidprovider.com. Это может быть имя пользователя / пароль, это могут быть информационные карточки, сертификаты браузера, отпечатки пальцев, смарт-карты, внеполосные механизмы, такие как проверка звонка, ... Как он обрабатывает аутентификацию, зависит от davidsopenidprovider.com. Затем он спрашивает, действительно ли вы хотите войти на relyingparty.com. 5) Если вы успешно вошли в систему на davidsopenidprovider.com, вы будете перенаправлены обратно на relyingparty.com и автоматически войдете там. 6) davidsopenidprovider.com только гарантирует relyingparty.com, что вы являетесь тем, кем себя называете. Он не отправляет пароль.
Итак, ваше предположение: «Как потребитель, когда я создаю учетную запись на any-site.com, я не имею понятия об интеллекте разработчиков / менеджеров сайта». неверно в отношении OpenID. Если есть слабое место, то это провайдер, а не any-site.com. Это проблема с традиционными логинами по имени пользователя и паролю. Вы должны доверять каждому сайту, который предлагает такой способ входа в систему, а не только одному - вашему провайдеру OpenID.
Надеюсь, это поможет понять OpenID.
Откуда вы знаете, что они делают?
Точно так же вы знаете, что любой старый сайт передает ваш пароль кому-то другому - вы этого не делаете. Вот почему вы используете компанию с хорошей репутацией.
Вы никогда не сможете изменить свой OP, не изменив также свой OpenID.
Что вы можете. Посмотрите на делегирование OpenID.
Мой OpenID http://ceejayoz.com/, но мой OP - WordPress.com. Два META
теги в заголовке http://ceejayoz.com/ позвольте мне сделать это, и я могу изменить это в любое время.
Ваш openID - ваш провайдер. pwnguin.net
это мой openID. Это не подлежит гаданию, это просто известный факт. Что защищает мой openID, так это программное обеспечение, работающее на pwnguin.net, которое отвечает утвердительно только в том случае, если у данного посетителя есть файл cookie аутентификации.
Я не скажу, что openID безопасен; существуют всевозможные межсайтовые сценарии, которые могут продолжаться, или некоторые обыденные детали, которые я склонен игнорировать или ошибаться.
Вот что я почерпнул из ответов здесь ...
OpenID безопасен настолько, насколько защищены участвующие стороны, и это верно для любого метода аутентификации. Я понял это еще до того, как начал это обсуждение.
Проблема с OpenID, как мне кажется, двоякая ...
Ваш LoginID больше не является секретом, доступным только вам и сайту, на котором вы его используете. Это ваш OpenID, который известен каждому сайту, на котором вы его используете, и представляет собой нечто, что легко угадать, например, адрес электронной почты или что-то полученное из вашего адреса электронной почты или что-то подобное.
RP могут внедрять OpenIP на своих сайтах без должной осмотрительности, предполагая, что поскольку они используют общепринятый «протокол», он безопасен. Конечно, большинство заурядных разработчиков веб-сайтов не имеют истинного представления о том, как защитить сайт, но, если они реализуют собственную безопасность, по крайней мере, проблема №1 не вступает в игру.
Как потребитель, когда я создаю учетную запись на any-site.com, я не имею понятия об уровне интеллекта разработчиков / менеджеров сайта. Я использую идентификатор, который, не думаю, будет легко угадать. Я не хочу, чтобы serverfault.com знал идентификатор, который я использую для входа на Etrade.com. Я также использую разные пароли на каждом сайте и управляю этими паролями по своей собственной схеме. Маловероятно, что мой аккаунт будет включен, если только операторы сайта не являются полными идиотами.
С OpenID каждый в WEB знает, как он работает и как атаковать, если RP не примет надлежащих мер.
Я люблю программное обеспечение с открытым исходным кодом, но в случае с OpenID я думаю, что это открывает возможность того, что для ничего не подозревающих пользователей будут доступны худшие реализации.
Я думаю, что все это можно решить с помощью какой-нибудь подписанной печати одобрения, которая гарантирует потребителю, что сайт прошел аудит и не защищен от взлома.
Может, я просто параноик.