14.5. Аутентификация в веб-сервисах

В настоящий момент HTTP (вместе с HTTPS) является основным протоколом, используемым в сети Интернет для доступа к веб-сервисам (например к социальным сетям или веб-клиентам электронной почты). Данный протокол является протоколом типа «запрос-ответ», причём для каждого запроса открывается новое соединение с сервером

Для версии протокола HTTP/1.0 существует неофициальное [48] расширение в виде заголовка Connection: Keep-Alive, который позволяет использовать одно соединение для нескольких запросов. Версия протокола HTTP/1.1 по умолчанию [38] устанавливает поддержку выполнения нескольких запросов в рамках одного соединения. Однако все запросы всё равно выполняются независимо друг от друга.

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

Аутентификация в веб-сервисах также бывает односторонней (как со стороны клиента, так и со стороны сервиса) и взаимной. Под аутентификацией веб-сервиса обычно понимается возможность сервиса доказать клиенту, что он является именно тем веб-сервисом, к которому хочет получить доступ пользователь, а не его мошеннической подменой, созданной злоумышленниками. Для аутентификации веб-сервисов используется механизм сертификатов открытых ключей протокола HTTPS с использованием инфраструктуры открытых ключей (см. раздел 9.5).

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

14.5.1. Первичная аутентификация по паролю

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

Более защищённым, но малоиспользуемым способом аутентификации является вычисление хеша от пароля $m$, «соли» $s$ и псевдослучайных одноразовых меток $n_1, n_2$ с помощью JavaScript в браузере и отсылка по сети только результата вычисления хеша.

$$ \begin{array}{ll} \text{Браузер} ~\rightarrow~ \text{Сервис:} & \text{HTTP GET-запрос,} \\ \text{Браузер} ~\leftarrow~ \text{Сервис:} & s ~\|~ n_1, \\ \text{Браузер} ~\rightarrow~ \text{Сервис:} & n_2 ~\|~ h( h(s ~\|~ m) ~\|~ n_1 ~\|~ n_2). \\ \end{array} $$

Если веб-сервис хранит хеш от пароля и «соли» $h(s ~\|~ m)$, то пароль не может быть перехвачен ни по сети, ни веб-сервисом, ни какими-либо прокси-серверами, находящимися между браузером и веб-сервисом.

В массовых интернет-сервисах пароли часто хранятся в открытом виде на сервере, что не является хорошей практикой для обеспечения защиты персональных данных пользователей.

14.5.2. Первичная аутентификация в OpenID

Из-за большого числа различных логинов, которые приходится использовать для доступа к различным сервисам, постепенно происходит внедрение единых систем аутентификации для различных сервисов (single sign-on), например OpenID. Одновременно происходит концентрация пользователей вокруг больших порталов с единой аутентификацией, например Google Account. Яндекс.Паспорт также уменьшает число используемых паролей для различных служб.

Принцип аутентификации состоит в следующем.

Веб-сервисы доверяют аутентификацию пользователя третьей стороне – центру аутентификации. Центров может быть несколько, но владельцы веб-сервиса могут ограничить выбор такого центра «белым» или «чёрным» списком.
Когда пользователь заходит на интернет-ресурс, веб-приложение перенаправляет его на центр аутентификации с защитой TLS-соединением.
Центр аутентифицирует пользователя и выдаёт ему токен аутентификации, который пользователь предъявляет интернет-сервису.
Сервис по токену аутентификации определяет имя пользователя.

Рис. 14.1 — Схема аутентификации в OpenID

На рис. 14.1 показана схема аутентификации в OpenID версии 2 для доступа к стороннему интернет-сервису.

Если сервис и центр вместе создают общий секретный ключ $K$ для имитовставки ${\textrm{MAC}}_K$, выполняются шаги 4, 5 по протоколу Диффи — Хеллмана:

$$ \begin{array}{l} \text{4. Сервис} ~\rightarrow~ \text{центр: модуль}~ p ~\text{группы}~ {{\mathbb{Z}}}_p^*, ~\text{генератор}~ g, \\ ~~~~~~~~~~~~~~~\text{число}~ g^a \mod p, \\ \text{5. Сервис} ~\leftarrow~ \text{центр: число}~ g^b \mod p, ~\text{гаммированный} \\ ~~~~~~~~~~~~~~~\text{ключ}~ K \oplus (g^{ab} \mod p), \end{array} $$

то аутентификатор содержит ${\textrm{MAC}}_K$, проверяемый шагом 10 на выданном ключе $K$

Более правильным подходом является использование в качестве ключа $K = g^{ab} \mod p$, так как в этом случае ключ создаётся совместно, а не выдаётся центром.

. Имитовставка определяется как описанный ранее ${\textrm{HMAC}}$ с хеш-функцией SHA-256.

Если сервис и центр не создают общий ключ (этапы 4, 5 не выполняются), то сервис делает запрос на проверку аутентификатора в шагах 10, 11.

В OpenID аутентификатор состоит из следующих основных полей: имени пользователя, URL сервиса, результата аутентификации в OpenID, одноразовой метки и, возможно, кода аутентификации от полей аутентификатора на секретном ключе $K$, если он был создан на этапах 4, 5. Одноразовая метка является одноразовым псевдослучайным идентификатором результата аутентификации, который центр сохраняет в своей БД. По одноразовой метке сервис запрашивает центр о верности результата аутентификации на этапах 10, 11. Одноразовая метка дополнительно защищает от атак воспроизведения.

Можно было бы исключить шаги 4, 5, 10, 11, но тогда сервису пришлось бы реализовывать и хранить в БД использованные одноразовые метки для защиты от атак воспроизведения. Цель OpenID – предоставить аутентификацию с минимальными издержками на интеграцию. Поэтому в OpenID реализуется модель, в которой сервис делегирует все проверки центру с помощью соответствующих запросов.

Важно отметить, что в аутентификации через OpenID необходимо использовать TLS-соединения (то есть протокол HTTPS) при всех взаимодействиях с центром, так как в самом протоколе OpenID не производится аутентификация сервиса и центра, конфиденциальность и целостность не поддерживаются.

14.5.3. Вторичная аутентификация по cookie

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

Первым способом является автоматическая модификация на стороне сервера вывода страницы клиенту, которая добавляет ко всем URL в HTML-коде страницы этот токен. В результате, переходя по ссылкам на HTML-странице (а также заполняя формы и отправляя их на сервер), клиент будет автоматически отправлять токен как часть запроса в URL-адресе страницы: http://tempuri.org/page.html?token=12345.
Вторым способом является использование механизма cookie («куки», «кукиз», на русский обычно не переводится, подробнее см. [48]). Данный механизм позволяет серверу передать пользователю некоторую строку, которая будет отправляться на сервер при каждом последующем запросе.

Основным механизмом для вторичной аутентификации пользователей в веб-сервисах является механизм cookie, а токены, как часть URL, используются в распределённых системах, наподобие уже рассмотренной OpenID, так как сервисы, находящиеся в разных доменах, не имеют доступа к общим cookie. Далее рассмотрим подробнее механизм использования cookie.

Когда браузер в первый раз делает HTTP-запрос:

GET /index.html HTTP/1.1
Host: www.wikipedia.org
Accept: */*

В заголовок ответа сервера веб-приложение может добавить заголовок Set-Cookie, который содержит новые значения cookie:

HTTP/1.1 200 OK
Content-type: text/html
Set-Cookie: name1=value1; name2=value2; ...

...далее HTML-страница...

Браузер, если это разрешено настройками, при последующих запросах к веб-серверу автоматически будет отсылать cookie назад веб-приложению:

GET /wiki/HTTP_cookie HTTP/1.1
Host: www.wikipedia.org
Cookie: name1=value1; name2=value2; ...
Accept: */*

Далее веб-приложение может создать новый cookie, изменить значение старого и т. д. Браузер хранит cookie на устройстве клиента. То есть cookie позволяет хранить переменные на устройстве клиента, отсылать сохранённые значения, получать новые переменные. В результате создаётся передача состояний, что даёт возможность не вводить логин и пароль каждый раз при входе в интернет-сервис, использовать несколько окон для одного сеанса работы в интернет-магазине и т. д. При создании cookie может указываться его конечное время действия, после которого браузер удалит устаревший cookie.

Для вторичной аутентификации в cookie веб-приложение записывает токен в виде текстовой строки. В качестве токена можно использовать псевдослучайную текстовую строку достаточной длины, созданную веб-приложением. Например:

Cookie: auth=B35NMVNASUY26MMWNVZ87.

В этом случае веб-сервис должен вести журнал выданных токенов пользователям и их сроков действия. Если информационная система небольшого размера (один или десятки серверов), то вместо журнала может использоваться механизм session storage.

При первом заходе на сайт сервер приложений (платформа исполнения веб-приложения) «назначает» клиенту сессию, отправляя ему через механизм cookie новый (псевдо-)случайный токен сессии, а в памяти сервера выделяя структуру, которая недоступна самому клиенту, но которая соответствует данной конкретной сессии.
При каждом последующем обращении клиент передаёт токен (идентификатор) сессии с помощью механизма cookie. Сервер приложений берёт из памяти соответствующую структуру сессии и передаёт её приложению вместе с параметрами запроса.
В момент прохождения первичной аутентификации приложение добавляет в указанную область памяти ссылку на информацию о пользователе.
При последующих обращениях приложение использует информацию о пользователе, записанную в области памяти сессии клиента.
Сессия автоматически стирается из памяти после прохождения некоторого времени неактивности клиента (что контролируется настройками сервера) либо если приложение явно вызвало функцию инвалидации сессии (англ. invalidate).

Плюсом использования session storage является то, что этот механизм уже реализован в большинстве платформ для построения веб-приложений (см., например, [20]). Его минусом является сложность синхронизации структур сессий в памяти серверов для распределённых информационных систем большого размера.

Вторым способом вторичной аутентификации с использованием cookie является непосредственное включение аутентификационных данных (идентификатор пользователя, срок действия) в cookie вместо случайного токена. К данным в обязательном порядке добавляется имитовставка по ключу, который известен только сервису. С одной стороны, данный подход может значительно увеличить размер передаваемых cookie. С другой – он облегчает вторичную аутентификацию в распределённых системах, так как промежуточным сервисом, хранящим информацию о произошедшей аутентификации, является только клиент, а не сервер.

Конечно, беспокоиться об аутентификации в веб-сервисах при использовании обычного HTTP-протокола без защиты канала с помощью TLS-соединения (HTTPS-протокола) имеет смысл только по отношению к угадыванию токенов аутентификации другими пользователями, не имеющих доступа к маршрутизаторам и сети, через которые клиент общается с сервисом (в том числе к радиоканалу используемой Wi-Fi сети). Кража компьютера или одного cookie-файла и перехват незащищённого трафика протокола HTTP приводят к доступу в систему под именем взломанного пользователя.