15:32 OpenID | |
| OpenID - это открытый стандарт и децентрализованный протокол аутентификации . Продвигаемая некоммерческим OpenID Foundation , она позволяет пользователям проходить аутентификацию на взаимодействующих сайтах (известных как проверяющие стороны или RP) с использованием сторонних сервисов, устраняя необходимость для веб-мастеров предоставлять свои собственные специальные системы входа в систему, и позволяя пользователям входить на несколько не связанных между собой веб-сайтов без необходимости иметь отдельную идентификационную информацию и пароль для каждого. Пользователи создают учетные записи, выбирая поставщика удостоверений OpenID , а затем используют эти учетные записи для входа на любой веб-сайт, который принимает проверку подлинности OpenID. В соответствии с OpenID Foundation несколько крупных организаций выпускают или принимают OpenID на своих веб-сайтах. тандарт OpenID обеспечивает основу для взаимодействия, которое должно происходить между провайдером идентификации и акцептором OpenID (« проверяющая сторона »). Расширение стандарта (OpenID Attribute Exchange) облегчает передачу пользовательских атрибутов, таких как имя и пол, от провайдера идентификации OpenID проверяющей стороне (каждая проверяющая сторона может запросить различный набор атрибутов, в зависимости от его требования). Протокол OpenID не полагается на центральный орган для аутентификации личности пользователя. Более того, ни сервисы, ни стандарт OpenID не могут требовать специальных средств для аутентификации пользователей, допускающих подходы, начиная от общего (например, пароли) и заканчивая романом (например, смарт-карты или биометрические данные ). Термин OpenID также может относиться к идентификатору, как указано в стандарте OpenID; Эти идентификаторы принимают форму уникального универсального идентификатора ресурса (URI) и управляются неким «провайдером OpenID», который обрабатывает аутентификацию Вход в систему Конечный пользователь взаимодействует с проверяющей стороной (такой как веб-сайт), которая предоставляет возможность указать OpenID для целей аутентификации; конечный пользователь обычно ранее регистрировал OpenID (например alice.openid.example.org) у поставщика OpenID (например openid.example.org). Проверяющая сторона обычно преобразует OpenID в каноническую форму URL (например, http://alice.openid.example.org/). С OpenID 1.0 проверяющая сторона затем запрашивает ресурс HTML, идентифицированный URL-адресом, и считывает тег HTML-ссылки, чтобы обнаружить URL-адрес поставщика OpenID (например http://openid.example.org/openid-auth.php). Проверяющая сторона также обнаруживает, использовать ли делегированную личность (см. Ниже). При использовании OpenID 2.0 проверяющая сторона обнаруживает URL-адрес поставщика OpenID, запрашивая документ XRDS (также называемый документ Yadis ) с типом содержимого application/xrds+xml; этот документ может быть доступен по целевому URL и всегда доступен для целевого XRI. Существует два режима, в которых проверяющая сторона может связываться с поставщиком OpenID: checkid_immediate, в котором проверяющая сторона запрашивает, чтобы поставщик OpenID не взаимодействовал с конечным пользователем. Вся связь передается через пользовательский агент конечного пользователя без явного уведомления конечного пользователя. checkid_setupв котором конечный пользователь связывается с поставщиком OpenID через того же агента пользователя, который использовался для доступа к проверяющей стороне. checkid_immediateРежим может упасть обратно в checkid_setupрежим , если операция не может быть автоматизирована. Сначала проверяющая сторона и поставщик OpenID (необязательно) устанавливают общий секрет , на который ссылается ассоциированный дескриптор , который затем хранит проверяющая сторона. При использовании checkid_setupрежима проверяющая сторона перенаправляет пользовательский агент конечного пользователя поставщику OpenID, чтобы конечный пользователь мог проходить проверку подлинности непосредственно с поставщиком OpenID. Способ аутентификации может различаться, но обычно поставщик OpenID запрашивает у конечного пользователя пароль или какой-либо криптографический токен, а затем спрашивает, доверяет ли конечный пользователь проверяющей стороне для получения необходимых идентификационных данных. Если конечный пользователь отклоняет запрос поставщика OpenID на доверие доверяющей стороне, то пользовательский агент перенаправляется обратно проверяющей стороне с сообщением, указывающим, что аутентификация была отклонена; проверяющая сторона в свою очередь отказывается аутентифицировать конечного пользователя. Если конечный пользователь принимает запрос поставщика OpenID на доверие доверяющей стороне, то агент пользователя перенаправляется обратно проверяющей стороне вместе с учетными данными конечного пользователя. Затем эта проверяющая сторона должна подтвердить, что учетные данные действительно получены от поставщика OpenID. Если проверяющая сторона и поставщик OpenID ранее установили общий секретный ключ, то проверяющая сторона может проверить личность поставщика OpenID, сравнив свою копию общего секретного ключа с полученной вместе с учетными данными конечного пользователя; такая проверяющая сторона называется отслеживающей, поскольку она хранит общий секрет между сеансами. Напротив, не имеющая состояния или немая проверяющая сторона должна сделать еще один фоновый запрос (check_authentication), чтобы данные действительно были получены от поставщика OpenID. После того, как OpenID был проверен, аутентификация считается успешной, и конечный пользователь считается зарегистрированным во проверяющей стороне под идентификатором, заданным данным OpenID (например alice.openid.example.org). Затем проверяющая сторона обычно сохраняет OpenID конечного пользователя вместе с другой информацией о сеансе конечного пользователя. Идентификаторы Чтобы получить URL - адрес с поддержкой OpenID, который можно использовать для входа на веб-сайты с поддержкой OpenID, пользователь регистрирует идентификатор OpenID у провайдера идентификации. Поставщики удостоверений предлагают возможность зарегистрировать URL-адрес (обычно домен третьего уровня, например, username.example.com), который будет автоматически настроен с помощью службы аутентификации OpenID. После регистрации OpenID пользователь также может использовать существующий URL-адрес под своим собственным контролем (например, блог или домашняя страница) в качестве псевдонима или «делегированной идентификационной информации». Они просто вставляют соответствующие теги OpenID в HTML или подают документ Yadis . Начиная с OpenID Authentication 2.0 (и некоторых реализаций 1.1), есть два типа идентификаторов, которые можно использовать с OpenID: URL-адреса и XRI. XRI - это новая форма интернет- идентификатора, разработанная специально для междоменной цифровой идентификации. Например, XRI бывают двух форм: i-имена и i-номера , которые обычно регистрируются одновременно как синонимы . Я-имена могут быть переназначены (например, доменные имена), а я-номера никогда не переназначаются. Когда в качестве идентификатора OpenID используется i-имя XRI, оно немедленно преобразуется в синонимичный i-номер (элемент CanonicalID документа XRDS). Этот i-номер является идентификатором OpenID, который хранится проверяющей стороной. Таким образом, и пользователь, и проверяющая сторона защищены от идентификации OpenID конечного пользователя, когда-либо перенесенной другой стороной, как это может случиться с URL-адресом на основе переназначаемого DNS-имени. Перехват аутентификации в незащищенном соединении Еще одна важная уязвимость присутствует на последнем этапе схемы аутентификации, когда TLS / SSL не используются: URL-адрес перенаправления от поставщика удостоверений к проверяющей стороне. Проблема с этим перенаправлением заключается в том, что любой, кто может получить этот URL (например, прослушивая провод), может воспроизвести его и войти на сайт как пользователь-жертва. Некоторые из провайдеров идентификации используют одноразовые номера(номер используется один раз), чтобы пользователь мог зайти на сайт один раз и потерпеть неудачу во всех последовательных попытках. Решение nonce работает, если пользователь первым использует URL. Однако быстрый злоумышленник, отслеживающий соединение, может получить URL-адрес и немедленно сбросить TCP-соединение пользователя (поскольку злоумышленник прослушивает соединение и знает требуемые порядковые номера TCP), а затем выполнить атаку воспроизведения, как описано выше. Таким образом, одноразовые номера защищают только от пассивных атакующих, но не могут помешать активным атакующим выполнить атаку повторного воспроизведения. Использование TLS / SSL в процессе аутентификации может значительно снизить этот риск. Это можно переформулировать как: IF (как RP1, так и RP2 имеют Боба в качестве клиента) И // общий случай (Боб использует один и тот же IDP как с RP1, так и с RP2) И // общий случай (RP1 не использует VPN / SSL / TLS для защиты своего соединения с клиентом) // предотвратимо! ТОГДА RP2 может получить учетные данные, достаточные для олицетворения Боба с RP1 END-IF OpenID - это способ использования единого набора учетных данных пользователя для доступа к нескольким сайтам, а OAuth упрощает авторизацию одного сайта для доступа и использования информации, связанной с учетной записью пользователя, на другом сайте. Хотя OAuth не является протоколом аутентификации , его можно использовать как часть одного. Атака против псевдо-аутентификации OpenID предоставляет механизм криптографической проверки, который предотвращает приведенную ниже атаку против пользователей, которые используют OAuth для аутентификации. Обратите внимание, что ключ камердинера никоим образом не описывает пользователя, он лишь предоставляет ограниченные права доступа к некоторому дому (который даже не обязательно является пользователем, у него просто был ключ). Поэтому, если ключ становится скомпрометированным (пользователь является злонамеренным и сумел украсть ключ в чужом доме), тогда пользователь может выдать себя за владельца дома за приложение, которое запросило их подлинность. Если ключ скомпрометирован какой-либо точкой в цепочке доверия, злоумышленник может перехватить его и использовать для олицетворения пользователя X для любого приложения, использующего OAuth2 для псевдо-аутентификации на том же сервере авторизации OAuth. И наоборот, нотариально заверенное письмо содержит подпись пользователя, которая может быть проверена запрашивающим приложением против пользователя, поэтому эта атака нежизнеспособна Проверка письма Письмо может использовать криптографию с открытым ключом для аутентификации. Запрашивающее приложение предоставляет свой открытый ключ шифрования пользователю, который передает его на сервер аутентификации. Сервер аутентификации зашифровывает документ, содержащий ключ шифрования, который соответствует одностороннему хэшу секрета, который пользователь знает (например, ключевую фразу) для ответа на запрос, используя открытый ключ приложения. Пользователь передает зашифрованный документ обратно в приложение, которое его расшифровывает. Приложение зашифровывает случайную фразу, используя полученный ключ шифрования, и запрашивает, что пользователь делает то же самое, затем сравнивает результаты, если они совпадают, пользователь аутентичен. | |
|
| |
| Всього коментарів: 0 | |