Pull to refresh

Безопасность при авторизации на сайтах по OpenID

Reading time 8 min
Views 23K
OpenID — это открытая децентрализованная система, которая позволяет пользователю использовать единый аккаунт для аутентификации на множестве не связанных друг с другом сайтов, порталов, блогов и форумов. Если WEB сайт предполагает использование аутентификации или авторизации пользователя, то возможные варианты реализации этого приведены ниже:
1) Использовать стандартную регистрацию через ввод email и заполнения необходимых данных.
2) Использовать аутентификацию через указание личного идентификатора OpenID провайдера.
3) Использовать авторизацию через открытый протокол OAuth

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



1) Цель использования OpenID авторизации

Основная цель использования OpenID – это упрощение регистрации пользователя. Упрощение достигается в децентрализованной системе единого входа, которая позволяет использовать один логин и пароль на большом количестве сайтов. На сайтах, поддерживающих OpenID, пользователям не приходится каждый раз регистрироваться и помнить данные для каждого сайта. Вместо этого им достаточно быть зарегистрированными на сайте «провайдера идентификации» OpenID (предоставляющего идентификатор). Так как технология OpenID децентрализованная, то любой сайт может использовать программное обеспечение OpenID в качестве средства входа. Удобство OpenID также заключается в том, что при авторизации по OpenID, посещаемому сайту сразу могут передаваться личные данные пользователя (email, Имя, пол, дата рождения и др) и ему не придется каждый раз вводить данную информацию — достаточно это сделать один раз на сайте OpenID провайдера.

2) Принцип работы OpenID авторизации

Принцип работы OpenID авторизации рассмотрим на примере.
Пользователь через WEB браузер заходит на некоторый интересующий его сайт(по официальной терминологии в OpenID — Relying Party, RP). Предположим, что далее пользователь хочет оставить комментарий на одном из блогов сайта. Без поддержки сайтом технологии OpenID пользователю будет предложено зарегистрироваться, что подразумевает создание или получение очередного логина и пароля. Если сайт поддерживает технологию OpenID, то рядом с полем регистрации будет обозначен входа по OpenID (чаще всего обозначено логотипом OpenID ). Далее пользователь может ввести OpenID-адрес — адрес персональной страницы пользователя на сервере OpenID провайдера (OP). Для примера, если пользователь получил свой OpenID на сайте Яндекса, то этот OpenID имеет вид username.ya.ru («username» — это логин пользователя на yandex.ru). Дальнейший процесс авторизации показан на диаграмме ниже


Ниже показаны скриншоты при авторизации на сайте www.livejournal.com при помощи OpenID идентификатора, выданным OpenID провайдером myopenid.com
a. Пользователь хочет написать комментарий на сайте www.livejournal.com. При этом он еще не регистрировался на сайте, но имеет OpenID идентификатор у провайдера myopenid.com
b. Пользователь открывает сайт www.livejournal.com
c. Далее пользователь выбирает способ авторизации через OpenID и авторизуется на сайте провайдера OpenID.




d) OpenID провайдер предлагает ввести пароль, который заводился пользователем ранее, на этапе создания OpenID аккаунта. Далее мы рассмотрим ниже на какие особенности надо обращать пользователю на этом шаге.


e) пользователь вводит свой логин и пароль OpenID провайдера, после чего происходит аутентификация пользователя на сайте www.livejournal.com.


f) через мгновение, в браузере появляется сайт www.livejournal.com, где пользователь уже аутентифицирован и может писать комментарии.


3) Аналоги OpenID

Кроме OpenID существуют и другие способы использовать ресурсы сайта не регистрируясь.
a) Прежде всего рассмотрим технологию единого входа через «Single sign on». Технологии очень похожи по принципу работы, но есть некоторые отличия:
— Если на веб-портале существует несколько обширных независимых разделов (форум, чат, блог и т. д.), то пройдя процедуру аутентификации по технологии Single sign on в одном из сервисов, человек автоматически получает доступ ко всем остальным, что избавляет его от многократного ввода данных своей учетной записи. Здесь функции OpenID и Single sign on похожи.
— «Single sign on», в отличии от OpenID, является централизованной, что подразумевает возможность использования аккаунта только внутри некой системы, например, внутри корпоративной сети. Например, пользователь водит логин и пароль и аутентификация проходит в неком доверенном корпоративном ресурсе (например, Active Directory). Далее, возможна автоматическая авторизация во многих приложениях и программах данной корпоративной сети (в том числе и в IE). Если пользователя покидает корпоративную сеть, то пользоваться Single sign on аккаунтом он уже не сможет.

b) Открытый протокол авторизации OAuth. Позволяет предоставить третьей стороне ограниченный доступ к защищенным ресурсам пользователя без необходимости передавать ей (третьей стороне) логин и пароль. Примерами OAuth провайдеров приведены по ссылке ru.wikipedia.org/wiki/OAuth. Существует ошибочное мнение, что OAuth является расширением протокола OpenID, на самом деле это не так. Хотя OpenID и OAuth имеют много общего, последний является самостоятельным протоколом, никак не связанным с OpenID.
OAuth является протоколом авторизации, который позволяет предоставить права на использование какого-то ресурса (например, API какого-либо сервиса). Например, авторизуюсь через OpenID на сайте livejournal.com через OAuth провайдера vkontakte.ru, последний может предоставлять постоянные доступ к некоторой информации пользователя.
OpenID является средством аутентификации: с помощью этой системы можно удостовериться, что пользователь — именно тот, за кого себя выдает. Какие действия сможет совершать пользователь, прошедший аутентификацию посредством OpenID, определяется стороной, проводящей аутентификацию.

4) Крупные OpenID провайдеры и написание свого OpenID сервера

Некоторый список OpenID провайдеров приведен на сайте openid.net/get-an-openid. При выборе OpenID провайдера пользователю нужно быть осторожным, так как не факт, что мелкий провайдер не будет распространять во вне данные пользователя и что данный провайдер не закроется через год, что приведет к необходимости создания нового OpenID идентификатора уже у другого провайдера.
Для продвинутых пользователей существует возможность авторизации по OpenID с указанием URL своего сайта (например, www.ivan-petrov.ru), который, в свою очередь, будет пересылать запрос на авторизацию на тот OP (OpenID provider), который указан в HTML заголовке. В этом случае, при смене OpenID провайдера достаточно поменять код своей заглавной HTML страницы, а URL для авторизации по OpenID остается тот же – в нашем примере, www.ivan-petrov.ru. Использование своего сайта как идентификатора OpenID возможно на тех сайтах, которые предлагаю авторизоваться, указав URL OpenID. На LiveJournal.com это возможно.
Если пользователь вообще не доверяет сторонним OpenID провайдерам, то при небольших навыках программирования он может написать свой собственный OpenID сервер и использовать его как для своей авторизации так и для раздачи OpenID идентификаторов другим пользователям (см пример на www.opennet.ru/base/dev/openid_server.txt.html).

5) Анализ безопасности OpenID

К сожалению, спецификация на технологию OpenID (в данный момент OpenID Authentication 2.0) не описывает каким образом обеспечивается безопасность авторизации при использовании OpenID.
В связи с этим, в интернете ведутся длительные дискуссии по способам получения злоумышленниками конфиденциальных данных пользователя (например, пароля к своему OpenID аккаунту). Ben Laurie описал простой сценарий, при котором ваши login/пароль к OpenID-провайдеру (OP), например, LiveJournal, могут стать легкой добычей фишеров если не проявлять осторожность. В общих чертах, сценарий такой:
a) Пользователь заходит на некий сайт, например, для просмотра фотографий. Если пользователь хочет оставить комментарий под фотографией, то единственное что просит сайт — это зарегистрироваться или аутентифицироваться по OpenID. Пользователь выбирает OpenID, пишет туда, например, user_xxx.livejournal.com, и отправляет форму.
b) По общему принципу работы OpenID, пользователя теперь должны отправить на www.livejournal.com/openid/server.bml. Если пользователь уже аутентифицирован в livejournal.com, то сайту с фотографиями будет возращен признак успешной аутентификации и высланы дополнительные параметры. Если же нет — LiveJournal попросит прежде ввести login/пароль. Это в теории. На практике, сайт с фотографиями может принадлежать злоумышленникам, и вместо OP endpoint может отправить пользователя на свой прокси, замаскировав url соотвествующим образом, например www.livejournal.com/openid/server.bml?lot_of_junk@evilcats.example.com. Пользователь увидит перед собой ту же страницу с livejournal.com, на которой нужно ввести свои данные, только показана она будет через прокси evilcats.example.com и login/пароль к livejournal.com останутся в логах прокси сервера. Таким образом, если пользователь не будет внимательно следить за тем на каком URL странице он вводит свой логин и пароль, то существует вероятность получения этих данных злоумышленниками. Этот факт является сдерживающим фактором быстрого распространения технологии OpenID.
Некоторые пользователи, ведущие блоги по OpenID активно обсуждают как можно избежать указанного выше сценария. Например, предлагается следующие способы защиты:
a) Вариант генерации разового пароля:
— организация SSL канала между пользователем из OpenID провайдером
— наличие на ПК пользователя специальной cookie, которая записывается при первом обращении на сайт OpenID провайдера
— Cookie пересылается пользователю при подтверждении пароля, высланного на его емайл OpenID провайдером. Также Cookie храниться на стороне OpenID провайдера, и которая должна совпадать.
— Cookie высылается по SSL на ПК пользователя только после корректного ввода пароля
— При последующих аутентификациях по OpenID на различных сайтах, OpenID провайдер сверяет Cookie с той что получена от ПК и далее выводит специальную картинку, которую знает только пользователь и которая загружена на сервере OpenID провайдера. Если пользователь не видит данную картинку, значит реального общения с OpenID сервером не происходит.
Данный метод позволяет улучшить аутентификацию по OpenID, но требует включенных cookie в браузере, также появляется дополнительное звено в виде пароля на email.

b) Другим, более универсальным способом повышения безопасности при использовании OpenID является появление специальных плагинов в браузере пользователя. Без данного плагина вводить OpenID пароль пользователю не рекомендуется. Однако не факт, что данные плагины будут делать все основные разработчики браузеров.

c) И третий способ, это использование SSL сертификатов при аутентификации у OpenID провайдера. Данный способ, с одной стороны повышает безопасность и облегчает аутентификацию, так как пользователю не нужно вводить пароль. С другой стороны, сертификат может быть получен злоумышленником через трояны. Кроме того, поддержка SSL сертификатов есть только у крупных OpenID провайдеров, например myopenid.com.

Также надо отметить, что некоторые OP не принимают OpenID, зарегистрированный у другого OP и это несколько меняет определение ЕДИНОГО OpenID идентификатора.

6) Стандарты

— OpenID Authentication 2.0
openid.net/specs/openid-authentication-2_0.html

— OpenID Attribute Exchange 1.0
openid.net/specs/openid-attribute-exchange-1_0.html

— OpenID Simple Registration Extension 1.0
openid.net/specs/openid-simple-registration-extension-1_0.html

— Yadis Discovery Protocol (Developed separately from OpenID)
svn.infogrid.org/infogrid/docs/yadis/yadis-v1.0.pdf

Выводы

1. Технология OpenID является удобным способом аутентификации на сайтах, поддерживающих данную технологию.
2. Владельцу OpenID не нужно хранить множество паролей для различных сайтов и предоставлять свой email адрес, ему нужно только знать URL на свой OpenID аккаунт и пароль к нему.
3. При аутентификации и поддержании активной сессии на сайте OpenID провайдера, аутентификации на других сайтах по OpenID будет проходить без ввода пароля, только путем указания URL своего OpenID.
4. Спецификацией версии 2.0 не обеспечивается должный уровень безопасности при использовании OpenID. Возможно улучшение безопасности в новых версиях спецификаций или при разработке и использовании специальных плагинов для Web браузеров (для ПК/PDA/Mobile browsers). Пока, для повышения безопасности опытным пользователям можно посоветовать регистрацию у OpenID провайдеров, предоставляющих SSL сертификаты.
5. Разработчики WEB сайтов и сервисов без труда могут добавить функционал аутентификации по OpenID, так как все необходимые для этого библиотеки свободно предоставляются. Поддержка аутентификации по OpenID существенно повышает usability сайта, что является предпосылкой к развитию данной концепции.
Tags:
Hubs:
+2
Comments 8
Comments Comments 8

Articles