Обзор алгоритмов аутентификации в распределенных программных системах

Авторы: О.С. Грищенко, А.В. Чернышова

Аннотация:

Грищенко О.С., Чернышова А.В. Обзор алгоритмов аутентификации в распределенных программных системах. Представлен обзор существующих алгоритмов аутентификации, используемых в современных распределенных системах. Рассмотрен принцип работы некоторых распространенных протоколов аутентификации. Рассмотрены новые подходы к аутентификации в распределенных системах.

Постановка задачи

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

Цель работы

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

Аутентификация в xmpp

Протокол  обмена сообщениями XMPP использует для аутентификации Simple Authentication and Security Layer protocol (SASL)[1]. SASL позволяет определить аутентификацию на абстрактном уровне. Таким образом, он отделяет механизмы аутентификации от прикладных протоколов передачи данных, и позволяет использовать любые механизмы аутентификации, поддерживающиеся SASL, использовать в любых прикладных протоколах. SASL поддерживает такие механизмы аутентификации: DIGEST-MD5, PLAIN, TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA, EXTERNAL, ANONYMOUS, OTP, KERBEROS, GSSAPI, SecurID, NTLM

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

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

Основным недостатком SASL является уязвимость перед  атаками типа "человек в середине". Проведение такой атаки позволяет злоумышленнику выбрать наименее защищённый механизм из поддерживаемых.

Аутентификация в telegram

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

Генерация ключа авторизации происходит с использованием криптографических алгоритмов AES, RSA и Диффи-Хэлмана.

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

Можно выделить следующие недостатки:

- перехват sms, если не используется дополнительный пароль, приводит к взлому аккаунта;

- при краже телефона, если не используется дополнительный пароль, злоумышленник получает доступ к аккаунту пользователя.

Аутентификация в cerberos

Первым этапом пользователь должен пройти аутентификацию в KDC. Для этого клиент отправляет на сервер KDC свой идентификатор. KDC отправляет клиенту билет на получение билета (TGT – Ticket Granting Tiket) зашифрованный секретным ключом, сгенерированным на основе пароля пользователя. Если пользователь ввел правильный пароль, то клиентское ПО сможет расшифровать TGT и получить доступ к локальной рабочей станции. К каждому последующему запросу к KDC клиент будет добавлять TGT.[3]

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

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

Клиент может потребовать у сервера проведения взаимной аутентификации.

Также для Kerberos существует расширение PKI NIT, позволяющее проводить описанную процедуру с использованием алгоритмов ассиметричного шифрования.

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

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

- для корректной работы протокола необходима синхронизация часов всех участников информационного обмена;

- необходимо наличие сервера с запущенной службой KDS;

- дополнительные сложности администрирования;

- слабым местом протокола является пароль пользователя, который может быть недостаточно надежным.

Аутентификация с использованием протокола U2F

Рассмотрим общий алгоритм взаимодействия с U2F (универсальный второй фактор) на стороне браузера. Пользователь проходит верификацию логина и пароля. Проверяющая сторона (сервер) запрашивает подпись вызова(challenge). Браузер пересылает запрос устройству(usb токену). Если пользователь подтвердил свое желание произвести двухфакторную аутентификацию, то устройство возвращает подпись вызова. Браузер передает подпись проверяющей стороне. Проверяющая сторона верифицирует подпись.

U2F выдвигает к аппаратным имплементациям такие требования:

- для защиты от клонирования U2F устройство должно иметь встроенный счетчик;

- все имплементации должны активироваться пользователем (через нажатие на кнопку, ввод пин-кода, снятие отпечатка пальца или другое действие);

- U2F устройство должно иметь встроенный партийный сертификат. [4]

Процедура регистрации представлена на рисунке 1[5].

 

Рисунок 1 – Регистрация с использованием U2F

 

Процедура аутентификации представлена на рисунке 2[5].

 

Рисунок 2 – Аутентификация с использованием U2F

 

При потере U2F ключа предусмотрен резервный способ двухфакторной аутентификации в виде кода по смс или email.[6]

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

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

Можно выделить следующие недостатки:

- конечный пользователь должен сам подключить дополнительную аутентификацию сервисах;

- пользователю необходимо приобрести usb токен, удовлетворяющий описанным требованиям безопасности;

- многие сервисы, на данный момент, не поддерживают U2F;

- протокол предполагает использование HTTPS соединения.

Протокол SQRL

SQRL использует один автоматически генерируемый мастер-пароль для доступа к каждому веб-сайту и приложению

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

 

Рисунок 3 – Схема работы протокола SQRL

 

При попытке входа генерируется QR код, содержащий, URL-адрес службы аутентификации (может совпадать с адресом самого сайта или сервиса) и некоторую случайно сгенерированную строку. Клиентское SQRL приложение считывает информацию из QRкода и проводит следующие преобразования:

- из мастер-ключа и URL-адреса службы аутентификации, с помощью алгоритма HMAC, получают приватный ключ;

- для полученного приватного ключа генерируется публичный ключ;

-для URL-адреса службы аутентификации и случайно сгенерированной строки, полученных от сервера, создается электронная цифровая подпись;

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

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

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

Можно выделить следующие недостатки:

- на данный момент не поддерживается большинством существующих сервисов;

- при краже телефона защита всех аккаунтов, зарегистрированных с помощью этого телефона, обеспечивается только средствами защиты установленного клиентского приложения (например, пароль для запуска приложения), которые не регламентируются протоколом;

- на момент написания статьи существует всего два клиентских приложения для операционной системы Android, реализующих протокол SQRL;

- требует наличия смартфона.

Выводы

Из рассмотренных методов аутентификации наилучшую защиту предоставляет протокол Cerberos. Однако, для его использования необходима настройка соответствующей инфраструктуры и ее дальнейшее администрирование. Таким образом, протокол может успешно использоваться для доступа к ресурсам внутри предприятия, но, например, для отдельных веб сервисов, он практически не применим. Хорошие перспективы распространения имеет протокол SQRL, предлагающий более защищенную альтернативу аутентификации по логину и паролю. Высокий уровень безопасности при аутентификации обеспечивает протокол U2F. Протокол является универсальным и его распространение может привести к значительному усилению защиты пользовательских аккаунтов. Но U2F описывает только дополнительный фактор аутентификции и требует приобретения специализированного устройства. Кроме того надежность аутентификации зависит от конкретных реализаций данного протокола (в первой очереди аппаратной). Аутентификация в Telegrm является удобной и достаточно надежной, но, защита, в случае кражи телефона или перехвата sms кода, обеспечивается только дополнительным паролем (если он настроен пользователем). Таким образом существующие протоколы аутентификации имеют свои преимущества, недостатки и области применения, которые нужно учитывать при использовании того или иного протокола.

Литература

 

1.    Simple Authentication and Security Layer [Electronic resourse] / Интернет-ресурс. - Режим доступа: https://www.isode.com/products/sasl.html - Загл. с экрана.

2.    Механизмы SASL [Electronic resourse] / Интернет-ресурс. - Режим доступа: http://www.bog.pp.ru/work/SASL.html#mechanisms. - Загл. с экрана.

3.    Практика информационной безопасности [Electronic resourse] / Интернет-ресурс. - Режим доступа: http://dorlov.blogspot.com/2009/09/issp-02-5.html. - Загл. с экрана.

4.    FIDO U2F — Универсальная Двухфакторная Аутентификация. Введение. [Electronic resourse] / Интернет-ресурс. - Режим доступа: https://habrahabr.ru/post/305508/. - Загл. с экрана.

5.    FIDO U2F 1.0 Specs: Overview and Insights [Electronic resourse] / Интернет-ресурс. - Режим доступа: https://www.slideshare.net/FIDOAlliance/fido-u2f-10-specs-overview-and-insights-60000802. - Загл. с экрана.

6.    Двухфакторная аутентификация на примере JaCarta U2F [Electronic resourse] / Интернет-ресурс. - Режим доступа: https://habrahabr.ru/company/aladdinrd/blog/347032/. - Загл. с экрана.