Digest Access Authentication¶

Digest Access Authentication — это протокол аутентификации, используемый в протоколе передачи гипертекста (HTTP) для проверки подлинности клиента (обычно веб-браузера) перед сервером. В отличие от более простой базовой аутентификации (Basic Access Authentication), Digest Access Authentication не передаёт пароль в открытом виде, а использует криптографическую хеш-функцию для создания дайджеста (свертки) от пароля, имени пользователя и других параметров запроса. Это обеспечивает более высокий уровень безопасности при передаче данных по незащищённым каналам связи, хотя и не является полноценной заменой протоколам шифрования, таким как TLS.

¶История

Протокол Digest Access Authentication был разработан как часть спецификации HTTP/1.1 и впервые описан в документе RFC 2069, опубликованном в январе 1997 года. Его создание было ответом на критику базовой аутентификации, которая передавала пароль в кодировке Base64, что делало её уязвимой для перехвата. В 1999 году вышла обновлённая версия RFC 2617, которая уточнила механизмы, ввела поддержку хеширования методом MD5-sess и улучшила защиту от атак типа «человек посередине» (MITM). Позднее, в 2015 году, спецификация была пересмотрена в RFC 7616, где были добавлены поддержка хеш-функции SHA-256 и возможность использования алгоритмов SHA-512/256, что повысило криптостойкость протокола.

Несмотря на появление более современных методов аутентификации, таких как OAuth и OpenID Connect, Digest Access Authentication остаётся востребованным во встроенных системах, устаревшем программном обеспечении и в сценариях, где внедрение TLS затруднено или невозможно.

¶Принцип работы

Протокол основан на модели «вызов-ответ» (challenge-response). Процесс аутентификации состоит из нескольких этапов:

1. Запрос без аутентификации: Клиент отправляет HTTP-запрос к защищённому ресурсу без указания учётных данных.
2. Ответ сервера с вызовом: Сервер отклоняет запрос с кодом состояния 401 Unauthorized и добавляет в заголовок WWW-Authenticate параметры вызова: realm (область защиты), nonce (одноразовое число, генерируемое сервером), opaque (необязательное значение, возвращаемое клиентом без изменений), algorithm (алгоритм хеширования, например, MD5 или SHA-256) и qop (качество защиты — auth или auth-int).
3. Формирование ответа клиентом: Клиент вычисляет дайджест (хеш) на основе пароля, имени пользователя, realm, nonce, метода HTTP-запроса (GET, POST и т.д.) и URI запрашиваемого ресурса. Если используется qop=auth-int, в вычисление также включается хеш тела запроса, что обеспечивает целостность данных.
4. Отправка аутентифицированного запроса: Клиент повторяет запрос, добавляя заголовок Authorization, который содержит имя пользователя, realm, nonce, uri, response (вычисленный дайджест), opaque (если был получен), qop и nc (счётчик nonce — число, увеличивающееся с каждым запросом для предотвращения повторных атак).
5. Проверка сервером: Сервер получает запрос, извлекает пароль пользователя из своей базы данных (или из хранилища, где пароль может храниться в виде хеша), вычисляет ожидаемый дайджест по тому же алгоритму, что и клиент, и сравнивает его с полученным значением response. Если значения совпадают, аутентификация считается успешной.

¶Классификация и параметры

¶Алгоритмы хеширования

• MD5 (RFC 2617): Наиболее распространённый, но устаревший алгоритм. Уязвим к коллизиям, однако в контексте Digest Access Authentication его использование всё ещё может быть приемлемо при отсутствии высоких требований к безопасности.
• SHA-256 (RFC 7616): Рекомендуемый современный алгоритм, обеспечивающий более высокую криптостойкость. Поддерживается большинством современных серверов и клиентов.
• SHA-512/256 (RFC 7616): Вариант SHA-512 с усечением до 256 бит, обеспечивающий повышенную производительность на 64-битных системах.

¶Качество защиты (Quality of Protection, qop)

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

¶Параметры вызова

• realm: Строка, идентифицирующая область защиты (например, «Доступ к административной панели»). Используется для группировки ресурсов с одинаковыми учётными данными.
• nonce: Уникальное одноразовое число, генерируемое сервером. Обычно включает временную метку и случайное значение для предотвращения повторных атак.
• opaque: Произвольная строка, возвращаемая клиентом без изменений. Может использоваться для поддержания состояния сессии.
• domain: Список URI, к которым применим данный вызов. Позволяет клиенту заранее знать, какие ресурсы защищены.
• stale: Флаг, указывающий, что предыдущий nonce устарел, но аутентификация может быть продолжена с новым nonce.

¶Преимущества и недостатки

¶Преимущества

• Отсутствие передачи пароля в открытом виде: Пароль не передаётся по сети, а используется только для вычисления дайджеста. Это снижает риск перехвата учётных данных.
• Защита от повторных атак: Использование nonce и счётчика nc делает невозможным повторное использование перехваченного запроса.
• Поддержка целостности данных: При использовании qop=auth-int протокол проверяет, что тело запроса не было изменено.
• Простота реализации: Не требует сложной инфраструктуры управления сессиями или токенами.

¶Недостатки

• Уязвимость к атакам «человек посередине» (MITM): Если злоумышленник может перехватить и модифицировать заголовки, он может заставить клиента использовать более слабый алгоритм (например, MD5 вместо SHA-256) или подменить realm. Для защиты от этого требуется использование TLS.
• Не защищает содержимое: Даже при qop=auth-int данные передаются в открытом виде, если не используется шифрование (например, HTTPS).
• Сложность с хранением паролей: Сервер должен хранить пароли в виде, позволяющем вычислить дайджест (обычно в открытом виде или с использованием хеша, специфичного для Digest). Это противоречит современным практикам хранения паролей (например, bcrypt, Argon2).
• Ограниченная поддержка в современных веб-приложениях: Многие современные фреймворки и API предпочитают токены (JWT) или OAuth, так как они более гибкие и безопасные.

¶Применение

Digest Access Authentication используется в следующих сценариях:

• Встроенные системы и IoT-устройства: В условиях ограниченных вычислительных ресурсов и отсутствия возможности установки TLS (например, из-за ограничений по памяти или производительности) Digest обеспечивает минимально приемлемый уровень безопасности.
• Устаревшие системы: Многие старые веб-серверы, маршрутизаторы, принтеры и сетевые хранилища (NAS) поддерживают только Digest или Basic аутентификацию.
• Административные интерфейсы: В некоторых корпоративных системах Digest используется для защиты панелей управления, где внедрение HTTPS может быть затруднено из-за сетевых политик.
• Прокси-серверы: HTTP-прокси могут использовать Digest для аутентификации клиентов, запрашивающих доступ к внешним ресурсам.

¶Критика

Основная критика Digest Access Authentication связана с его уязвимостью к атакам, если не используется TLS. Злоумышленник, контролирующий сеть, может:

• Понизить алгоритм хеширования до MD5.
• Подменить realm, чтобы получить доступ к другому ресурсу.
• Перехватить и модифицировать тело запроса, если qop не установлен в auth-int.

Кроме того, протокол не обеспечивает взаимной аутентификации (клиент не проверяет подлинность сервера), что делает его уязвимым для фишинговых атак. В связи с этим современные рекомендации (например, от IETF) предписывают использовать Digest только в сочетании с HTTPS.

¶Интересные факты

• Несмотря на то, что Digest Access Authentication считается устаревшим, он до сих пор поддерживается всеми основными веб-браузерами, включая Google Chrome, Mozilla Firefox и Safari.
• В RFC 7616 была добавлена возможность использования алгоритма SHA-256, что делает протокол более устойчивым к атакам, но не решает фундаментальных проблем с MITM.
• В некоторых реализациях Digest используется для аутентификации в протоколе SIP (Session Initiation Protocol), который применяется в VoIP-телефонии.

¶Источники

• RFC 2069 — An Extension to HTTP: Digest Access Authentication (1997)
• RFC 2617 — HTTP Authentication: Basic and Digest Access Authentication (1999)
• RFC 7616 — HTTP Digest Access Authentication (2015)
• «HTTP: The Definitive Guide» by David Gourley and Brian Totty (2002)
• «Web Security: A WhiteHat Perspective» by Hanqing Wu and Liz Zhao (2015)