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:

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

Предоставление сертификата пользователю^[8]

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

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

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

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

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

Пример предоставления сертификата^[9]

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

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

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

Генерация утверждения^[8]

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

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

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

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

Верификация утверждения^[8]

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

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

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

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

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

Анализ протокола.^[10]

Кража или потеря ключа

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

Конфиденциальность

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

Надежность

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

Недостатки протокола

Нет встроенной защиты от фишинга.^[11]

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

Нет отслеживания передачи почтового адреса новому пользователю

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

Примечания

1. ↑ ^{1 2} Persona| MDN
2. ↑ Mozilla представила конкурента OpenID
3. ↑ Introducing BrowserID: A better way to sign in
4. ↑ Introducing BrowserID: BrowserID deployments at Mozilla
5. ↑ Introducing Mozilla Persona
6. ↑ Announcing the First Beta Release of Persona
7. ↑ Why Persona?-Persona|MDN
8. ↑ ^{1 2 3 4} Protocol Overview
9. ↑ Identity Provider Overview
10. ↑ Michael Hackett and Kirstie Hawkey Security "Privacy and Usability Requirements for Federated Identity"
11. ↑ Michael Hackett and Kirstie Hawkey Security "Privacy and Usability Requirements for Federated Identity"

Ссылки