Mozilla Persona

Mozilla Persona
Генерация и верификация утверждения
Разработчик	Mozilla
Написана на	JavaScript
Первый выпуск	июль 2011
Репозиторий	github.com/mozilla/perso…
Лицензия	MPLv2.0[вд]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 перед тем, как запросить сертификат.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Michael Hackett, Kirstie Hawkey. Security, Privacy and Usability Requirements for Federated Identity (англ.). — Halifax, Nova Scotia, Canada, 2012. — P. 1—9. Архивировано 23 января 2013 года.
2. Harry Halpin. Web Authentication: The next step in the evolving identity eco-system? (англ.). — Boston, USA, 2012. — P. 3. Архивировано 1 июля 2013 года.

• Mozilla Persona official site (англ.). Архивировано из оригинала 8 марта 2013 года.
• Персона  (рус.). Дата обращения: 5 декабря 2012. Архивировано из оригинала 20 ноября 2012 года.
• How BrowserID Works (англ.). Архивировано из оригинала 4 февраля 2013 года.