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

HTTP
Способы запроса
Поля заголовка
Коды состояния ответа
Методы управления безопасным доступом
Уязвимости безопасности

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

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

Обзор

Проверка подлинности дайджест-доступа была первоначально указана в 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) , счетчик одноразового номера, увеличиваемый клиентом, и генерируемый клиентом случайный одноразовый номер. Эти улучшения предназначены для защиты, например, от криптоанализа атак с использованием выбранного открытого текста .

Если значение директивы алгоритма - "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 и Chrome, не поддерживает SHA-256 в качестве хэш-функции. По состоянию на октябрь 2021 года Firefox 93 официально поддерживает алгоритмы дайджест-аутентификации «SHA-256» и «SHA-256-sess». Однако поддержка алгоритмов «SHA-512-256», «SHA-512-256-sess» и хеширования имен пользователей по-прежнему отсутствует.

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

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

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

Рекомендации по проверке подлинности HTTP-дайджеста

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

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

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

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

Недостатки

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

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

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

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

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

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

Пример с объяснением

Следующий пример был первоначально приведен в 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="testrealm@host.com",
                        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>
Запрос клиента (логин "Mufasa", пароль "Circle Of Life")
GET /dir/index.html HTTP/1.0
Host: localhost
Authorization: Digest username="Mufasa",
                     realm="testrealm@host.com",
                     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), счетчика запросов (nc), одноразового номера клиента (cnonce), качества кода защиты (qop) и результата HA2. Результатом является значение «ответа», предоставленное клиентом.

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

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

   HA1 = MD5( "Mufasa:testrealm@host.com:Circle Of Life" )
       = 939e7578ed9e3c518a452acee763bce9

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

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

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

Сервер должен запоминать значения nonce, которые он недавно сгенерировал. Он также может помнить, когда было выдано каждое значение одноразового номера, истекая их через определенное время. Если используется просроченное значение, сервер должен ответить кодом состояния «401» и добавить stale=TRUEв заголовок аутентификации, указывая, что клиент должен повторно отправить с новым предоставленным 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.

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

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

Устаревшие

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

Смотрите также

Примечания

использованная литература

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