Дайджест аутентификация | это... Что такое Дайджест аутентификация? (original) (raw)

HTTP
Постоянное соединение · Сжатие · HTTPS
Методы
OPTIONS · GET · HEAD · POST · PUT · DELETE · TRACE · CONNECT · PATCH
Заголовки
Cookie · ETag · Location · Referer
DNT · X-Forwarded-For
Коды состояния
301 Moved permanently
302 Found
303 See Other
403 Forbidden
404 Not Found

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

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

Содержание

Обзор

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

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

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

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

RFC 2069 был позже заменен RFC 2617 (HTTP Аутентификация: обычная и дайджест проверка подлинности доступа). В RFC 2617 был введен ряд дополнительных мер по укреплению безопасности при дайджест аутентификации; «качество защиты» (QOP), счетчик случайных значений, увеличиваемый клиентом, и случайные значения, генерируемые клиентом. Эти улучшения предназначены для защиты от, например, атаки криптоаналитика с заранее выбранным открытым текстом [chosen-plaintext attack].

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

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

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

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

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

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

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

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

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

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

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

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

Схема HTTP была разработана в CERN в 1993 году и не включает в себя последующие улучшения систем аутентификации, такие как кодирование проверки подлинности сообщения с помощью хэш-ключа (HMAC). Хотя используемая криптографическая конструкция основывается на использовании MD5 хэш-функции, по общему мнению 2004 года атаки с коллизиями (collision attacks) не влияют на приложения, где открытый текст (например, пароль), не известен.[1][источник не указан 890 дней] Тем не менее, в 2006 году (Kim, Biryukov2, Preneel, Hong, «On the Security of HMAC and NMAC Based on HAVAL MD4 MD5 SHA-0 and SHA-1») было поставлено под сомнение, что другие применения MD5 настолько же удачны. Однако, до сих пор не было доказано, что атаки с коллизиями (collision attacks) на MD5 представляет угрозу для дайджест проверки подлинности, и RFC 2617 позволяет серверам внедрять механизмы, позволяющие выявить некоторые атаки с коллизиями (collision attacks) и повторами (replay attacks).

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

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

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

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

Недостатки

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

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

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

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

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

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

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

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

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

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

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

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="testrealm@host.com", qop="auth,auth-int", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", opaque="5ccc069c403ebaf9f0171e9517f40e41" Content-Type: text/html Content-Length: 311

Error

401 Unauthorized.

Запрос клиента (имя пользователя «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

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

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

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

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

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

SIP использует в основном тот же алгоритм дайджест аутентификации. Он определяется RFC 3261.

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

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

См. также

Литература

  1. ↑ Hash Collision Q&A. Cryptography Research ((date unidentified)). Архивировано из первоисточника 1 сентября 2004. Проверено 2 июля 2010. NOTE: Specific information not given; needs quote from exact version of this page originally cited.
  2. ↑ RFC 2617 — HTTP Authentication: Basic and Digest Access Authentication
  3. ↑ mod_auth_digest — Apache HTTP Server

Ссылки