Дайджест-проверка подлинности доступа

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

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

Обзор [ править ]

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

HA1 = MD5 (имя пользователя: область: пароль)HA2 = MD5 (метод: digestURI)ответ = MD5 (HA1: nonce: HA2)

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

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

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

HA1 = MD5 (имя пользователя: область: пароль)

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

HA1 = MD5 (MD5 (имя пользователя: область: пароль): nonce: cnonce)

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

HA2 = MD5 (метод: digestURI)

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

HA2 = MD5 (метод: digestURI: MD5 (entityBody))

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

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

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

ответ = MD5 (HA1: nonce: HA2)

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

В сентябре 2015 года RFC 7616 заменил RFC 2617 , добавив 4 новых алгоритма: «SHA-256», «SHA-256-sess», «SHA-512» и «SHA-512-sess». Кодирование эквивалентно алгоритмам «MD5» и «MD5-sess», при этом хеш-функция MD5 заменена на SHA-256 и SHA-512 .

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

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

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

Рекомендации по аутентификации дайджеста HTTP [ править ]

Преимущества [ править ]

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

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

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

Недостатки [ править ]

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

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

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

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

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

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

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

Пример с объяснением [ править ]

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

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

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

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

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

(за которым следует новая строка в виде возврата каретки с последующим переводом строки ). ^[6]

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

HTTP / 1.0  401  Неавторизованный сервер :  HTTPd / 0.9 Дата :  10 апреля 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 > Ошибка </ title >  </ head >  < body >  < h1 > 401 Несанкционировано. </ h1 >  </ body > </ html >

Запрос клиента (логин "Mufasa", пароль "Circle Of Life")

GET  /dir/index.html  HTTP / 1.0 Хост :  локальные авторизации :  Digest имя пользователя = "Муфас",  область = "[email protected]",  одноразовое значение = "dcd98b7102dd2f0e8b11d0f600bfb0c093",  URI = "/ реж / index.html",  QOP = auth,  nc = 00000001,  cnonce = "0a4f113b",  response = "6629fae49393a05397450978507c4ef1",  opaque = "5ccc069c403ebaf9f0171e9517f40e41"

(с пустой строкой, как и раньше).

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

HTTP / 1.0  200  OK Сервер :  HTTPd / 0.9 Дата :  10 апреля 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 («Муфаса: [email protected]: Круг жизни») = 939e7578ed9e3c518a452acee763bce9 HA2 = MD5 ("GET: /dir/index.html") = 39aff3a2bab6126f332b942af96d3366 Ответ = MD5 ("939e7578ed9e3c518a452acee763bce9: \ dcd98b7102dd2f0e8b11d0f600bfb0c093: \ 00000001: 0a4f113b: auth: \ 39aff3a2bab6126f332b942af96d3366 ") = 6629fae49393a05397450978507c4ef1

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

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

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

Файл .htdigest [ править ]

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

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

Синтаксис команды htdigest: ^[7]

htdigest [-c] имя пользователя области passwdfile

Формат файла .htdigest: ^[7]

user1: Область: 5ea41921c65387d904834f8403185412user2: Область: 734418f1e487083dc153890208b79379

Дайджест-аутентификация SIP [ править ]

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

Реализация браузера [ править ]

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

• Amaya
• На основе Gecko : (не включая auth-int ^[8] )
  • Пакет приложений Mozilla
  • Mozilla Firefox
  • Netscape 7+
• iCab 3.0.3+
• На основе KHTML и WebKit : (не включая auth-int ^[9] )
  • iCab 4
  • Konqueror
  • Гугл Хром
  • Сафари
• На основе Тасмана :
  • Internet Explorer для Mac
• На основе трезубца :
  • Internet Explorer 5+ ^[10] (не включая auth-int)
• На основе Presto :
  • Опера
  • Opera Mobile
  • опера мини
  • Браузер Nintendo DS
  • Браузер Nokia 770
  • Браузер Sony Mylo 1
  • Браузер интернет-каналов Wii

Устаревшие [ править ]

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

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

См. Также [ править ]

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

Заметки [ править ]

Ссылки [ править ]

Внешние ссылки [ править ]

• RFC 7235
• RFC 2617 (обновленный RFC 7235 )
• RFC 2069 (устаревший)