Дайджест-аутентификация доступа

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

Технически дайджест-аутентификация — это применение MD5 криптографического хеширования с использованием значений nonce для предотвращения атак повторного воспроизведения . Он использует протокол HTTP .

Этот стандарт устарел с июля 2011 года.

Обзор

Дайджест-аутентификация доступа изначально была указана RFC   2069 ( расширение HTTP: дайджест-аутентификация доступа ). , генерируемым сервером RFC 2069 определяет примерно традиционную схему дайджест-аутентификации с безопасностью, поддерживаемой значением nonce . Ответ аутентификации формируется следующим образом (где HA1 и HA2 — имена строковых переменных):

HA1 = MD5(username:realm:password)
HA2 = MD5(method:digestURI)
response = MD5(HA1:nonce:HA2)

Хэш MD5 представляет собой 16-байтовое значение. Значения HA1 и HA2, используемые при вычислении ответа, представляют собой шестнадцатеричное представление (в нижнем регистре) хешей MD5 соответственно.

RFC 2069 позже был заменен на RFC   2617 ( HTTP-аутентификация: базовая и дайджест-аутентификация доступа ). RFC 2617 представил ряд дополнительных улучшений безопасности для дайджест-аутентификации; «качество защиты» (qop) , счетчик nonce, увеличиваемый клиентом, и случайный nonce, сгенерированный клиентом. Эти усовершенствования предназначены для защиты, например, от атак с использованием выбранного открытого текста криптоанализа .

Если значение директивы алгоритма равно «MD5» или не указано, то HA1

HA1 = MD5(username:realm:password)

Если значение директивы алгоритма — «MD5-sess», то HA1

HA1 = MD5(MD5(username:realm:password):nonce:cnonce)

Если значение директивы qop равно «auth» или не указано, то HA2

HA2 = MD5(method:digestURI)

Если значение директивы qop равно «auth-int», то HA2

HA2 = MD5(method:digestURI:MD5(entityBody))

Если значение директивы qop равно «auth» или «auth-int», то ответ вычисляется следующим образом:

response = MD5(HA1:nonce:nonceCount:cnonce:qop:HA2)

Если директива qop не указана, вычислите ответ следующим образом:

response = MD5(HA1:nonce:HA2)

Вышеупомянутое показывает, что если qop не указан, используется более простой стандарт RFC 2069.

В сентябре 2015 года RFC 7616 заменил RFC 2617, добавив 4 новых алгоритма: «SHA-256», «SHA-256-sess», «SHA-512-256» и «SHA-512-256-sess». Кодировка эквивалентна алгоритмам «MD5» и «MD5-sess», с хэш-функцией MD5 , замененной на SHA-256 и SHA-512-256 . Однако по состоянию на июль 2021 г. , ни один из популярных браузеров, включая Firefox и Хром, поддержка SHA-256 в качестве хэш-функции. По состоянию на октябрь 2021 г. , Фаерфокс 93 официально поддерживает алгоритмы дайджест-аутентификации «SHA-256» и «SHA-256-sess». Однако поддержка алгоритмов «SHA-512-256», «SHA-512-256-sess» и хеширования имени пользователя. все еще не хватает. По состоянию на август 2023 г. , Chromium 117 (затем Chrome и Edge) поддерживает «SHA-256».

Влияние безопасности MD5 на дайджест-аутентификацию

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

Схема HTTP была разработана Филлипом Халламом-Бейкером в ЦЕРНе в 1993 году и не включает в себя последующие улучшения систем аутентификации, такие как разработка кода аутентификации сообщений с использованием хеш-ключа ( HMAC ). Хотя криптографическая используемая конструкция основана на хэш-функции MD5, в 2004 году считалось, что коллизионные атаки не влияют на приложения, в которых открытый текст (т. е. пароль) неизвестен. Однако претензии в 2006 г. вызывают некоторые сомнения и по поводу других приложений MD5.

Рекомендации по дайджест-аутентификации HTTP

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

Дайджест-аутентификация HTTP разработана так, чтобы быть более безопасной, чем традиционные схемы дайджест-аутентификации, например, «значительно более надежная, чем (например) CRAM-MD5 ...» (RFC 2617).

Некоторые из сильных сторон безопасности дайджест-аутентификации HTTP:

• Пароль не отправляется на сервер в открытом виде.
• Пароль не используется непосредственно в дайджесте, а используется HA1 = MD5(имя пользователя:область:пароль). Это позволяет некоторым реализациям (например, JBoss ) для хранения HA1, а не пароля в открытом виде (однако см. недостатки этого подхода)
• Клиентский nonce был введен в RFC 2617, что позволяет клиенту предотвращать атаки с использованием выбранного открытого текста , такие как радужные таблицы , которые в противном случае могли бы поставить под угрозу схемы дайджест-аутентификации.
• Серверный nonce может содержать временные метки. Таким образом, сервер может проверять атрибуты nonce, предоставленные клиентами, чтобы предотвратить атаки повторного воспроизведения.
• Серверу также разрешено вести список недавно выпущенных или использованных значений nonce сервера, чтобы предотвратить повторное использование.
• Это предотвращает фишинг , поскольку простой пароль никогда не отправляется ни на один сервер, будь то правильный сервер или нет. (Системы с открытым ключом полагаются на то, что пользователь может проверить правильность URL-адреса.)

Недостатки

У дайджест-аутентификации доступа есть несколько недостатков:

• Веб-сайт не контролирует пользовательский интерфейс, предоставляемый конечному пользователю.
• Многие параметры безопасности в RFC 2617 являются необязательными. Если качество защиты (qop) не указано на сервере, клиент будет работать в устаревшем режиме RFC 2069 с пониженной безопасностью.
• Дайджест-аутентификация доступа уязвима для атаки «человек посередине» (MITM) . Например, злоумышленник MITM может предложить клиентам использовать базовую аутентификацию доступа или устаревший режим аутентификации доступа RFC2069. Чтобы расширить это, дайджест-аутентификация доступа не предоставляет клиентам механизма проверки личности сервера.
• Сервер может хранить HA1 = MD5(имя пользователя:область:пароль) вместо самого пароля. Однако в случае утечки сохраненного HA1 злоумышленник может генерировать действительные ответы и получать доступ к документам в этой области так же легко, как если бы он имел доступ к самому паролю. Поэтому таблица значений HA1 должна быть защищена так же надежно, как и файл, содержащий пароли в виде открытого текста.
• Дайджест-аутентификация доступа предотвращает использование надежного хэша пароля (например, bcrypt ) при хранении паролей (поскольку либо пароль, либо дайджест-имя пользователя, область и пароль должны быть восстанавливаемыми).

Кроме того, поскольку алгоритм MD5 не разрешен в FIPS , аутентификация HTTP Digest не будет работать с сертифицированными FIPS криптомодули.

Альтернативные протоколы аутентификации

Безусловно, наиболее распространенным подходом является использование протокола аутентификации открытого текста на основе форм HTTP+HTML или, реже, базовой аутентификации доступа . Эти слабые протоколы открытого текста, используемые вместе с сетевым шифрованием HTTPS, устраняют многие угрозы, для предотвращения которых предназначена проверка подлинности доступа. Однако такое использование HTTPS предполагает, что конечный пользователь каждый раз точно проверяет, обращается ли он к правильному URL-адресу, чтобы предотвратить отправку своего пароля на ненадежный сервер, что приводит к фишинговым атакам. Пользователи часто не делают этого, поэтому фишинг стал наиболее распространенной формой нарушения безопасности.

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

• Аутентификация с открытым ключом (обычно реализуется с помощью HTTPS / SSL сертификата клиента ) с использованием сертификата клиента.
• Аутентификация Kerberos или SPNEGO , используемая, например, в Microsoft IIS, настроенном для встроенной аутентификации Windows (IWA).
• Протокол безопасного удаленного пароля (желательно на уровне HTTPS / TLS ). Однако это не реализовано ни в одном из основных браузеров.
• Веб-токен JSON (JWT) — это стандарт RFC 7519 на основе JSON для создания токенов доступа , которые подтверждают определенное количество утверждений.

Пример с пояснением

Следующий пример изначально был приведен в RFC 2617 и здесь расширен, чтобы показать полный текст, ожидаемый для каждого запроса и ответа . Обратите внимание, что распространяется только качество защитного кода «auth» (аутентификация) – по состоянию на апрель 2005 г. Известно , что только веб-браузеры Opera и Konqueror поддерживают «auth-int» (аутентификацию с защитой целостности). Хотя в спецификации упоминается HTTP версии 1.1, схему можно успешно добавить на сервер версии 1.0, как показано здесь.

Эта типичная транзакция состоит из следующих шагов:

1. Клиент запрашивает страницу, требующую аутентификации, но не предоставляет имя пользователя и пароль. Обычно это происходит потому, что пользователь просто ввел адрес или перешел по ссылке на страницу.
2. Сервер отвечает кодом ответа 401 «Неавторизованный» , предоставляя область аутентификации и случайно сгенерированное одноразовое значение, называемое nonce .
3. На этом этапе браузер предоставит пользователю область аутентификации (обычно описание компьютера или системы, к которой осуществляется доступ) и запросит имя пользователя и пароль. На этом этапе пользователь может принять решение об отмене.
4. После предоставления имени пользователя и пароля клиент повторно отправляет тот же запрос, но добавляет заголовок аутентификации, включающий код ответа.
5. В этом примере сервер принимает аутентификацию, и страница возвращается. Если имя пользователя недействительно и/или пароль неверен, сервер может вернуть код ответа «401», и клиент снова запросит у пользователя запрос.

---

Запрос клиента (без аутентификации)

GET /dir/index.html HTTP/1.0
Host: localhost

(за которым следует новая строка в виде возврата каретки и перевода строки ).

Ответ сервера

HTTP/1.0 401 Unauthorized
Server: HTTPd/0.9
Date: Sun, 10 Apr 2014 20:26:47 GMT
WWW-Authenticate: Digest realm="[email protected]",
                        qop="auth,auth-int",
                        nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
                        opaque="5ccc069c403ebaf9f0171e9517f40e41"
Content-Type: text/html
Content-Length: 153

<!DOCTYPE html>
<html>
  <head>
    <meta charset="UTF-8" />
    <title>Error</title>
  </head>
  <body>
    <h1>401 Unauthorized.</h1>
  </body>
</html>

Запрос клиента (имя пользователя «Муфаса», пароль «Круг Жизни»)

GET /dir/index.html HTTP/1.0
Host: localhost
Authorization: Digest username="Mufasa",
                     realm="[email protected]",
                     nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
                     uri="/dir/index.html",
                     qop=auth,
                     nc=00000001,
                     cnonce="0a4f113b",
                     response="6629fae49393a05397450978507c4ef1",
                     opaque="5ccc069c403ebaf9f0171e9517f40e41"

(за которым следует пустая строка, как и раньше).

Ответ сервера

HTTP/1.0 200 OK
Server: HTTPd/0.9
Date: Sun, 10 Apr 2005 20:27:03 GMT
Content-Type: text/html
Content-Length: 7984

(за которым следует пустая строка и HTML-текст страницы с ограниченным доступом).

---

Значение «отклика» рассчитывается в три этапа следующим образом. Если значения объединены, они разделяются двоеточиями.

1. Вычисляется хэш MD5 объединенного имени пользователя, области аутентификации и пароля. Результат обозначается как HA1.
2. MD5-хеш комбинированного метода и дайджеста URI , например: Вычисляется "GET" и "/dir/index.html". Результат обозначается как HA2.
3. Вычисляется MD5-хэш объединенного результата HA1, nonce сервера (nonce), счетчика запросов (nc), nonce клиента (cnonce), качества защитного кода (qop) и результата HA2. Результатом является значение «ответа», предоставленное клиентом.

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

Выполнение примера, приведенного в RFC 2617, дает следующие результаты для каждого шага.

   HA1 = MD5( "Mufasa:[email protected]:Circle Of Life" )
       = 939e7578ed9e3c518a452acee763bce9

   HA2 = MD5( "GET:/dir/index.html" )
       = 39aff3a2bab6126f332b942af96d3366

   Response = MD5( "939e7578ed9e3c518a452acee763bce9:\
                    dcd98b7102dd2f0e8b11d0f600bfb0c093:\
                    00000001:0a4f113b:auth:\
                    39aff3a2bab6126f332b942af96d3366" )
            = 6629fae49393a05397450978507c4ef1

На этом этапе клиент может сделать еще один запрос, повторно используя значение nonce сервера (сервер выдает новый nonce только для каждого ответа «401» ), но предоставляя новый nonce клиента (cnonce). Для последующих запросов шестнадцатеричный счетчик запросов (nc) должен быть больше последнего использованного значения – в противном случае злоумышленник может просто « воспроизвести » старый запрос с теми же учетными данными. Сервер должен гарантировать, что счетчик увеличивается для каждого из выданных им значений nonce, соответствующим образом отклоняя любые неверные запросы. Очевидно, что изменение метода, URI и/или значения счетчика приведет к другому значению ответа.

Сервер должен помнить значения nonce, которые он недавно сгенерировал. Он также может помнить, когда было выдано каждое значение nonce, и срок его действия истекает через определенное время. Если используется значение с истекшим сроком действия, сервер должен ответить кодом состояния «401» и добавить stale=TRUE в заголовок аутентификации, указывая, что клиент должен повторно отправить с новым предоставленным одноразовым номером, не запрашивая у пользователя другое имя пользователя и пароль.

Серверу не нужно хранить какие-либо значения nonce с истекшим сроком действия — он может просто предположить, что срок действия любых нераспознанных значений истек. Сервер также может разрешить возврат каждого значения nonce только один раз, хотя это вынуждает клиента повторять каждый запрос. Обратите внимание, что немедленное прекращение действия серверного nonce не сработает, поскольку клиент никогда не получит возможности его использовать.

Файл .htdigest

.htdigest — это плоский файл, используемый для хранения имен пользователей, области и паролей для дайджест-аутентификации HTTP-сервера Apache . Имя файла задается в конфигурации .htaccess и может быть любым, но каноническим именем является «.htdigest». Имя файла начинается с точки, поскольку большинство Unix-подобных операционных систем считают любой файл, имя которого начинается с точки, скрытым. Этот файл часто поддерживается с помощью команды оболочки «htdigest», которая может добавлять и обновлять пользователей, а также правильно закодировать пароль для использования.

Команда «htdigest» находится в пакете apache2-utils в системах управления пакетами dpkg и в пакете httpd-tools в системах управления пакетами RPM .

Синтаксис команды htdigest:

htdigest [ -c ] passwdfile realm username

Формат файла .htdigest:

user1:Realm:5ea41921c65387d904834f8403185412
user2:Realm:734418f1e487083dc153890208b79379

Дайджест-аутентификация SIP

Протокол инициации сеанса (SIP) использует в основном тот же алгоритм дайджест-аутентификации. Это указано в RFC 3261.

Реализация браузера

Большинство браузеров в значительной степени реализовали эту спецификацию, в некоторых запрещены определенные функции, такие как проверка аутентификации или алгоритм MD5-sess. Если сервер требует, чтобы эти дополнительные функции обрабатывались, клиенты могут не иметь возможности аутентифицироваться (хотя обратите внимание, что mod_auth_digest для Apache также не полностью реализует RFC 2617).

• Амайя
• На основе Gecko : (не включая auth-int )
  • Пакет приложений Mozilla
  • Мозилла Фаерфокс
  • Нетскейп 7+
• iCab 3.0.3+
• На основе KHTML и WebKit : (не включая auth-int )
  • iCab 4
  • Конкерор
  • Гугл Хром
  • Сафари
• Тасман - базируется:
  • Интернет Эксплорер для Mac
• На базе Трайдента :
  • Интернет Эксплорер 5+ (не включая auth-int)
• Престо - на основе:
  • Opera (Opera вышла из Presto в 2013 году)
  • Опера Мобайл
  • Опера Мини
  • Браузер Nintendo DS
  • Нокиа 770 Браузер
  • Sony Mylo 1 's Browser
  • Браузер интернет-каналов Wii

Устаревания

Из-за недостатков дайджест-аутентификации по сравнению с базовой аутентификацией через HTTPS она устарела во многих программах, например:

• Bitbucket: https://bitbucket.org/blog/fare-thee-well-digest-access-authentication
• PHP-фреймворк Symfony: https://github.com/symfony/symfony/issues/24325.

См. также

• АКА (безопасность)
• Веб-токен JSON (JWT)
• Базовая аутентификация доступа
• Аутентификация на основе форм HTTP+HTML

Внешние ссылки

• RFC 7235
• RFC 6331
• RFC 2617 (обновлен RFC 7235)
• RFC 2069 (устар.)