Способы аутентификации и их уязвимости

Аутентификация по паролю

Данный метод основывается на предоставлении пользователем username и password для идентификации и последующей аутентификации в системе. Данные (username и password) задаются пользователем при регистрации на ресурсе[1].

Основные стандартные протоколы для аутентификации по паролю:

• 1.    HTTP authentication. Данный протокол описан в стандартах HTTP 1.0/1.1, разработан давно, но до сих пор широко применяется т.к. поддерживается всеми браузерами и веб-серверами. Существует несколько схем аутентификации, отличающихся по уровню безопасности:

• •    Basic — самая простая схема, при которой username и password пользователя передаются в заголовке Authorization в

незашифрованном виде. Однако при использовании HTTPS протокола, является относительно безопасной.

• •    Digest — более безопасная альтернатива Basic схемы при незащищенных соединениях, но подвержена man-in-the-middle attacks(перехват и подмена сообщения)[2].

• •    NTLM (Windows authentication) — основана на challenge-response подходе, при котором пароль не передается в чистом виде. Данная схема не относится к стандарту HTTP, но поддерживается большинством браузеров и веб-серверов. Уязвима к pass-the-hash-атакам[3].

• 2.    Forms authentication. Для этого протокола не существует стандарта, поэтому все его реализации специфичны для конкретных систем. Данная система работает за счет отправки HTML-формы с введенными username/password на сервер через HTTP POST. В случае успеха веб-приложение создает session token, который помещается в cookie используемого браузера. В дальнейшем session token автоматически передается на сервер вместе с запросом. Уязвимостью данного протокола является возможность перехвата session token что зачастую дает тот-же уровень доступа, что и знание username/password. Поэтому для обеспечения безопасности все коммуникации между клиентом и сервером должны производиться только по защищенному соединению HTTPS.

• 3.    Иные протоколы аутентификации по паролю. Зачастую при разработке клиент-серверных приложений с использованием вебсервисов применяются нестандартные протоколы, в которых данные для аутентификации передаются в других частях HTTP запроса:

• •    URL query — является небезопасным, т. к. строки URL могут запоминаться браузерами, прокси и веб-серверами.

• •    Request body — безопасный вариант, однако применяется только для запросов, содержащих тело сообщения.

• •    HTTP header — оптимальный вариант, при этом может использоваться стандартный заголовок Authorization или другие произвольные заголовки.

Основными уязвимостями и ошибками в реализации данного метода являются:

• •    Возможность создания пользователями простых паролей.

• •    Возможность проведения brute-force атаки (полный перебор паролей).

• •    Самогенерируемые пароли не требующие от пользователя изменения пароля после первого входа.

• •    Возможность передачи паролей по незащищенному HTTP-соединению либо в строке URL.

• •    Использование приложением небезопасных хэш-функции для хранения паролей пользователей.

• •    Не требует повторной аутентификации пользователя для важных действий (таких как смена пароля).

• •    Создание session tokens так, что они могут быть подобраны для других пользователей.

• •    Возможность передачи session tokens по незащищенному HTTP-соединению, либо в строке URL.

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

Аутентификация по сертификатам

Сертификат    представляет     собой    набор     атрибутов, идентифицирующих владельца, подписанный certificate authority (CA). CA выступает в роли посредника, который гарантирует подлинность сертификатов. Также сертификат криптографически связан с закрытым ключом, которых хранится у владельца сертификата и позволяет однозначно подтвердить факт владения сертификатом[1].

В веб-приложениях используют сертификаты стандарта X.509. Аутентификация с помощью X.509-сертификата происходит в момент соединения с сервером и является частью протокола SSL/TLS.

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

Аутентификация по токенам

Данный способ аутентификации чаще всего применяется при построении распределенных систем Single Sign-On (SSO), где приложение делегирует функцию аутентификации пользователей другому[1].

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

Существует несколько распространенных форматов токенов:

• 1.    Simple Web Token (SWT) —самый простой формат, представляющий собой набор произвольных пар имя/значение в формате кодирования HTML form. Стандарт определяет несколько зарезервированных имен:  Issuer, Audience, ExpiresOn и HMACSHA256. Токен

• 2.    JSON Web Token (JWT) — содержит три блока, разделенных точками: заголовок, набор полей и подпись. Набор полей содержит

• 3.    Security Assertion Markup Language (SAML) — определяет токены в XML-формате, включающем информацию об эмитенте, о субъекте, необходимые условия для проверки токена, набор дополнительных утверждений о пользователе. Подпись SAML-токенов осуществляется при помощи ассиметричной криптографии. Кроме того, в отличие от предыдущих форматов, SAML-токены содержат механизм для подтверждения владения токеном, что позволяет предотвратить перехват токенов через man-in-the-middle-атаки при использовании           незащищенных           соединений.

подписывается с помощью симметричного ключа.

произвольные пары имя/значения. Подпись может генерироваться при помощи симметричных алгоритмов шифрования или асимметричных.

Среди наиболее популярных стандартов — OAuth, OpenID Connect, SAML, и WS-Federation.