Mozilla Persona

Материал из Википедии — свободной энциклопедии
Перейти к: навигация, поиск

Mozilla Persona — это децентрализованная система авторизации на сайтах, основанная на открытом протоколе BrowserID.[1]. Является конкурентом таких сервисов, как OpenID и OAuth. Продукт разработан компанией Mozilla. Разработчики утверждают, что Persona не следит за действиями пользователей. В настоящий момент сервис находится на стадии бета-версии[2].

История[править | править исходный текст]

  • 14 июля 2011 Заявление о начале разработки BrowserID - новой системы идентификации.[3]
  • 6 января 2012 Интеграция некоторых сервисов Mozilla с BrowserID в целях тестирования.[4]
  • 22 февраля 2012 Переименование системы. Новое название - Mozilla Persona, BrowserID остается названием только для открытого протокола.[5]
  • 27 сентября 2012 Выход первой бета-версии Mozilla Persona.[6]

Основные особенности[править | править исходный текст]

Адрес электронной почты в роли идентификатора[править | править исходный текст]

В системе Persona нет такого понятия, как логин для входа на сайт, пользователь идентифицируется при помощи одного из своих адресов электронной почты.[7] Такой подход избавляет пользователя от необходимости помнить логин для каждого сайта.

Вход без ввода пароля[править | править исходный текст]

Persona полностью избавляет от необходимости локального пароля для входа на сайт, освобождая пользователей и сайты от работ по созданию, управлению и безопасному хранению паролей. Пользователю требуется лишь зарегистрироваться один раз на Persona, и он сможет заходить на любые совместимые сайты, не затрачивая время на регистрацию.[1]

Участники процесса идентификации[править | править исходный текст]

Есть три основных участника процесса идентификации[8].

  1. Пользователь - человек, совершающий вход на сайт при помощи Persona.
  2. Проверяющая сторона - сайт, предоставляющий возможность входа с помощью Persona.
  3. Поставщик идентификации - домен, выдающий своим пользователям Persona-совместимые идентификационные сертификаты.

Persona и протокол BrowserID используют в роли идентификатора пользователя его адрес электронной почты, поэтому это вполне естественно, что обычно именно сервисы электронной почты являются поставщиками идентификации.

Механизм работы BrowserID[править | править исходный текст]

Можно выделить три основных этапа в работе протокола BrowserID[8]:

  1. предоставление сертификата пользователю,
  2. генерация утверждения,
  3. верификация утверждения.

Предоставление сертификата пользователю[править | править исходный текст]

Предоставление сертификата

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

Persona использует асимметричную схему для подписи, поэтому сертификат подписывается закрытым ключом поставщика идентификации. Сертификат содержит в себе следующую информацию:

  1. адрес электронной почты пользователя,
  2. открытый ключ для этого адреса, сгенерированный браузером пользователя,
  3. время выдачи сертификата,
  4. время истечения срока действия сертификата,
  5. доменное имя поставщика идентификации.

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

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

Пример предоставления сертификата[править | править исходный текст]

Рассмотрим процесс взаимодействия браузера пользователя и поставщика идентификации, в тот момент, когда Alice впервые использует адрес alice@example.com для входа на веб-сайт[9].

  1. Браузер Alice получает вспомогательный документ у поставщика идентификации, расположенный по адресу https://example.com/.well-known/browserid. Этот документ описывает порядок предоставления сертификата, а также может содержать инструкцию по перенаправлению к другому поставщику идентификации.
  2. Браузер в фоновом режиме загружает специальную страницу example.com для выдачи сертификатов, передаёт ему адрес почтового ящика alice@example.com и ассоциированный с ним открытый ключ, запрашивает подпись сертификата.
  3. Перед тем, как подписать ключ, поставщик идентификации example.com должен убедиться в том, что инициатором запроса сертификата является именно владелец почтового адреса Alice, поэтому поставщик идентификации сообщает ей через браузер о необходимости авторизации.
  4. Браузер загружает страницу авторизации на example.com, Alice представляется системе, устанавливается новый сеанс взаимодействия с example.com.
  5. Браузер перезагружает страницу для выдачи сертификата и ещё раз запрашивает подпись сертификата.
  6. На странице выдачи сертификата переданный адрес электронной почты сравнивается с инициализирующими данными сеанса. В случае соответствия example.com подписывает сертификат и отправляет его Alice.

Шаги 3-5 могут быть пропущены, если пользователь уже был авторизован на example.com перед тем, как запросить сертификат.

Генерация утверждения[править | править исходный текст]

Генерация и верификация утверждения

Для того, чтобы использовать сертификат для идентификации на "проверяющей стороне" пользователь должен предоставить доказательство принадлежности этого сертификата именно ему[8]. Для этого пользователь должен предоставить закрытый ключ из связки сгенерированной браузером и привязанной к адресу электронной почты, на который был выдан сертификат.

Перед тем как предоставить закрытый ключ, браузер пользователя создает и подписывает открытым ключом из связки новый документ, носящий название “утверждение идентификации”. Этот документ содержит в себе:

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

После этого браузер отправляет сертификат пользователя и идентификатор утверждения проверяющей стороне.

Верификация утверждения[править | править исходный текст]

Верификация утверждения - процесс проверки проверяющей стороной принадлежности почтового адреса пользователю[10].

Проверяющая сторона получает от браузера пользователя сертификат пользователя и утверждение идентификации[8].

На первом этапе верификации проверяющая сторона работает с "утверждением идентификации": проверяет название домена и время истечения срока действия утверждения. Утверждение отклоняется, если истекло время его действия или оно предназначено для другого домена. Такой подход предотвращает злонамеренное повторное использование утверждений.

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

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

После успешного прохождения всех этапов верификации пользователь сможет авторизоваться на сайте при помощи идентификатора содержащего в сертификате.

Характеристики защищенности протокола[править | править исходный текст]

Конфиденциальность[править | править исходный текст]

В процессе идентификации поставщик идентификации не получает никаких данных, по которым можно было бы определить сайт, на котором авторизуется пользователь. Таким образом поставщик идентификации не имеет возможности отслеживать сетевую активность пользователя[11].

Надежность[править | править исходный текст]

Для проверки подписи сертификата пользователя нужен открытый ключ поставщика идентификации. Этот ключ относительно постоянен, поэтому проверяющая сторона имеет возможность хранить его в памяти, предоставляя пользователю возможность идентификации с помощью сертификата, даже в ситуации отсутствия соединения с поставщиком идентификации[11].

Защита от кражи или потери ключа[править | править исходный текст]

Для того, чтобы уменьшить риск потери или неправомерного использования сертификата пользователя, время действия сертификата ограничивается (от нескольких минут до нескольких часов). Но тем не менее сертификат никак нельзя отменить, пока не истекло время его действия[12]. Кроме того, в то время как активна авторизованная сессия с поставщиком идентификации, поставщик автоматически снабжает пользователя новым сертификатом, по истечению действия старого, продолжительность такой сессии больше времени действия сертификата, порядка дня или даже недели. Можно сократить время устанавливаемой сессии для улучшения безопасности. Но нужно понимать, что чем короче сессия, тем чаще пользователь должен проходить повторную авторизацию на стороне поставщика идентификации. Это создает определенные неудобства для пользователя. Необходим некоторый компромисс между безопасностью и удобством.

Недостатки протокола[править | править исходный текст]

Нет встроенной защиты от фишинга[править | править исходный текст]

При попытке войти на сайт с помощью Mozilla Persona специальный JavaScript модуль выводит на экран пользователя окно выбора и создания идентификатора. Злоумышленник может подделать внешний вид этого окна с целью осуществления фишинга. Для пользователя существует единственный способ выявления подделки - проверка URL-адреса этого окна[13].

Нет отслеживания передачи почтового адреса новому пользователю[править | править исходный текст]

Электронный почтовый адрес, если долго не используется, становится неактивным.[14] Сервис электронной почты может предоставить этот адрес другому пользователю. Так как проверяющая сторона использует в виде идентификатора электронный почтовый адрес, новый владелец адреса сможет получить доступ ко всем данным предыдущего владельца, расположенных на сайте проверяющей стороны.

Примечания[править | править исходный текст]

Литература[править | править исходный текст]

  1. Michael Hackett, Kirstie Hawkey Security, Privacy and Usability Requirements for Federated Identity (англ.). — Halifax, Nova Scotia, Canada, 2012. — С. 1-9.
  2. Harry Halpin Web Authentication: The next step in the evolving identity eco-system? (англ.). — Boston, USA, 2012. — С. 3.

Ссылки[править | править исходный текст]