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

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

Обзор

Дайджест-аутентификация доступа была первоначально определена (An Extension to HTTP : Digest Access Authentication). задает почти классическую схему дайджест-аутентификации, в которой безопасность поддерживается с помощью генерируемых сервером случайных значений. Ответ на запрос аутентификации формируется следующим образом (где HA1, HA2, A1, A2 — имена строковых переменных):

${\displaystyle \mathrm {HA1} =\mathrm {MD5} {\Big (}\mathrm {A1} {\Big )}=\mathrm {MD5} {\Big (}\mathrm {username} :\mathrm {realm} :\mathrm {password} {\Big )}}$

${\displaystyle \mathrm {HA2} =\mathrm {MD5} {\Big (}\mathrm {A2} {\Big )}=\mathrm {MD5} {\Big (}\mathrm {method} :\mathrm {digestURI} {\Big )}}$

${\displaystyle \mathrm {response} =\mathrm {MD5} {\Big (}\mathrm {HA1} :\mathrm {nonce} :\mathrm {HA2} {\Big )}}$

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

${\displaystyle \mathrm {HA1} =\mathrm {MD5} {\Big (}\mathrm {A1} {\Big )}=\mathrm {MD5} {\Big (}\mathrm {username} :\mathrm {realm} :\mathrm {password} {\Big )}}$

Если значение директивы QOP равно «auth» или не определено, то HA2 равняется:

${\displaystyle \mathrm {HA2} =\mathrm {MD5} {\Big (}\mathrm {A2} {\Big )}=\mathrm {MD5} {\Big (}\mathrm {method} :\mathrm {digestURI} {\Big )}}$

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

${\displaystyle \mathrm {HA2} =\mathrm {MD5} {\Big (}\mathrm {A2} {\Big )}=\mathrm {MD5} {\Big (}\mathrm {method} :\mathrm {digestURI} :\mathrm {MD5} (entityBody){\Big )}}$

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

${\displaystyle \mathrm {response} =\mathrm {MD5} {\Big (}\mathrm {HA1} :\mathrm {nonce} :\mathrm {nonceCount} :\mathrm {clientNonce} :\mathrm {qop} :\mathrm {HA2} {\Big )}}$

Если директива QOP не определена, то ответ вычисляется так:

${\displaystyle \mathrm {response} =\mathrm {MD5} {\Big (}\mathrm {HA1} :\mathrm {nonce} :\mathrm {HA2} {\Big )}}$

Вышеизложенное показывает, что, когда QOP не определено, применяется более простой стандарт .

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

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

Схема HTTP была разработана в CERN в 1993 году и не включает в себя последующие улучшения систем аутентификации, такие как кодирование проверки подлинности сообщения с помощью хеш-ключа ( HMAC ).

Хотя используемая криптографическая конструкция основывается на использовании MD5 хеш-функции, по общему мнению 2004 года атаки с коллизиями ( Коллизионная атака ) не влияют на приложения, где открытый текст (например, пароль), не известен. ^{[ источник не указан 4945 дней ]}

Тем не менее, в 2006 году было поставлено под сомнение, что другие применения MD5 настолько же удачны. Однако до сих пор не было доказано, что атаки с коллизиями на MD5 представляет угрозу для дайджест-проверки подлинности, и позволяет серверам внедрять механизмы, позволяющие выявить некоторые атаки с коллизиями ( Коллизионная атака ) и повторами ( Атака повторного воспроизведения ).

Характеристики HTTP-дайджест-аутентификации

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

HTTP-дайджест-аутентификация создана для усиления защиты по сравнению с традиционными схемами дайджест-аутентификации, например, она "значительно более безопасна, чем CRAM-MD5 … " ( ).

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

• Пароль не используется непосредственно в дайджесте, вместо этого HA1 = MD5 (username: realm: password). Это позволяет в некоторых реализациях (например, JBoss ) хранить HA1, а не пароль открытым текстом .
• В было введено случайное значение клиента, которое позволяет клиенту предотвратить атаку с заранее выбранным открытым текстом (в противном случае, например, радужная таблица (rainbow table) представляет угрозу схеме дайджест-аутентификации).
• Серверное случайное значение может содержать временные метки. Поэтому сервер может проверить случайные значения, предоставленные клиентами, для предотвращения атак повторного воспроизведения (replay attack).
• Сервер также может содержать таблицу недавно созданных или использованных случайных значений для предотвращения повторного использования.

Недостатки

Дайджест-аутентификации доступа представляет собой компромиссное решение. Она призвана заменить незашифрованные HTTP базовой аутентификации доступа . Однако она не предназначена для замены более безопасных протоколов аутентификации, например, с открытым ключом или Kerberos -аутентификации.

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

• Многие из опций безопасности в являются необязательными. Если качество защиты (QOP) не определено сервером, клиент будет работать в режиме пониженной защищенности .
• Дайджест-аутентификация уязвима для атак человека посередине (MitM) . Например, MitM-злоумышленник может сказать клиентам использовать базовую аутентификацию доступа или режим дайджест-аутентификации . В более широком смысле, дайджест-аутентификация доступа не предоставляет клиентам механизма проверки подлинности сервера.
• Некоторые серверы требуют хранить пароли с использованием обратимого шифрования. Тем не менее, возможно вместо этого сохранять дайджест имени пользователя, области, и пароля.

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

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

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

Слабо защищённые протоколы открытого типа часто используются в:

• Схеме обычной проверки подлинности доступа
• Аутентификации на основе HTTP + HTML

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

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

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

Эта типичная схема обмена сообщениями состоит из следующих шагов.

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

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

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

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

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

HTTP/1.0 401 Unauthorized
Server: HTTPd/0.9
Date: Sun, 10 Apr 2005 20:26:47 GMT
WWW-Authenticate: Digest realm="[email protected]",
                        qop="auth,auth-int",
                        nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
                        opaque="5ccc069c403ebaf9f0171e9517f40e41"
Content-Type: text/html
Content-Length: 311
 
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
  "http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd">
<HTML>
  <HEAD>
    <TITLE>Error</TITLE>
    <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
  </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="[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

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

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

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

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

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

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

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

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

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

Наследуя идеологию и возможности HTTP, протокол SIP использует в основном тот же алгоритм дайджест-аутентификации. Он определяется в главе "22.4 The Digest Authentication Scheme".

Браузерная реализация

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

• Amaya
• На базе Gecko : (не включая auth-int: )
  • Mozilla Application Suite
  • Mozilla Firefox
• На базе KHTML и WebKit : (не включая auth-int )
  • Konqueror
  • Google Chrome
  • Safari
• На базе :
  • Internet Explorer for Mac
• На базе Trident :
  • Internet Explorer 7+ (не включая auth-int)
• На базе Presto :
  • Opera
  • Opera Mobile
  • Opera Mini
  • Браузер Nintendo DS
  • Nokia 770 Browser
  • Браузер
  • Браузер Wii Internet Channel

См. также

• Обычная проверка подлинности доступа
• Аутентификация в Интернете

Примечания

Ссылки

• (устарел)