Уязвимость OpenId для проверки подлинности

Question

Я уже давно использовал аутентификацию OpenId и помню пользователей, которые использовали RequestedIdentifier (в терминах DotNetOpenAuth) - строку, возвращаемую поставщиком OpenId после аутентификации.

Но внезапно я понял, что это решение имеет уязвимость. Представим себе, что есть провайдер 1 OpenId, который возвращает идентифицированный «идентификатор1» для пользователя 1. Теперь, если я знаю этот идентификатор, я могу запустить свой пользовательский провайдер OpenId и вернуть тот же идентификатор, поэтому я смогу войти в систему под пользователем 1.

Теперь я думаю о хранении openid_identifier (URL-адреса поставщика OpenId) + ClaimedIdentifier.

Я прав, думая? Разве я не пропустил какую-либо другую уязвимость?

Answer 1

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

Возможно, вы спрашиваете на этом этапе, так как это работает? Почему это не уязвимость?
Ответ исходит из того факта, что в любое время, когда поставщик (ОП) утверждает искомый идентификатор доверяющей стороне (RP), RP не просто доверяет OP. У него нет оснований доверять OP, потому что, как вы сказали, любой может настроить произвольный OP. Вместо этого RP принимает заявленный идентификатор и выполняет обнаружение на нем. По сути, RP запрашивает заявленный идентификатор: «У OP foo.com есть полномочия утверждать вашу личность?» Только истинный ОП для данного заявленного идентификатора сможет получить идентификатор, чтобы сказать «да» этому вопросу. Ответ «нет» заставит RP отклонить утверждение и сообщить пользователю, что во время аутентификации произошла ошибка.