Авторизация через .htaccess

Что требуется для работы аутентификации.

Чтобы наша аутентификация начала работать, потребуется создать 2 файла, один из которых чаще всего уже имеется – это файл .htaccess, если его нет, то необходимо его создать. В данном файле указываем следующие параметры:

Базовая схема аутентификации (Basic Authentication Scheme)

«Базовая» схема аутентификации (Basic Authentication Scheme) основана на модели, согласно которой клиент должен аутентифицировать себя с помощью идентификатора пользователя и пароля для каждой области. Значение области следует считать непрозрачной строкой, которую можно сравнить только на равенство с другими областями на этом сервере.

Для “Basic” вышеупомянутая структура используется следующим образом:

challenge = “Basic” realmcredentials = “Basic” basic-credentials

После получения неавторизованного запроса на URI в пределах пространства защиты сервер источника МОЖЕТ ответить на запрос, подобный следующему:

WWW-Authenticate: Basic realm=”WallyWorld”

где «WallyWorld» – это строка, назначенная сервером для идентификации защитного пространства “Request-URI”. Прокси может ответить тем же вызовом, используя поле заголовка “Proxy-Authenticate”.

1.3. Представление дайджест-значений

Необязательный заголовок позволяет серверу указать алгоритм, используемый для создания контрольной суммы или дайджеста. По умолчанию используется алгоритм MD5, и это единственный алгоритм, описанный в этом документе. Для целей этого документа дайджест MD5 из 128 битов представлен как 32 печатных символа ASCII.

Биты в 128-битном дайджесте преобразуются из старшего значащего в младший значащий бит по четыре бита за раз в их представление ASCII следующим образом. Каждые четыре бита представлены знакомыми шестнадцатеричными обозначениями из символов “0123456789abcdef”.

1.4. Ограничения

Схема дайджест-аутентификации (Digest authentication scheme), описанная в этом документе, страдает многими известными ограничениями. Она предназначена для замены обычной аутентификации и ничего более. Это система, основанная на пароле, и (на стороне сервера) страдает от всех тех же проблем, что и любая система паролей.

Пользователи и разработчики должны знать, что этот протокол не так безопасен, как “Kerberos”, и не так безопасен, как любая схема закрытого ключа на стороне клиента. Тем не менее, это лучше, чем ничего, лучше, чем то, что обычно используется с “telnet” и “ftp”, и лучше, чем обычная аутентификация “Basic”.

Дайджест схема аутентификации доступа концептуально аналогична базовой схеме. Форматы измененной строки заголовка “WWW-Authenticate” и строки заголовка “Authorization” указаны ниже. Кроме того, указывается новый заголовок “Authentication-Info”.

Если сервер получает запрос на объект, защищенный от доступа, и приемлемый заголовок авторизации не отправляется, сервер отвечает кодом состояния “401 неавторизован” и заголовком “WWW-Authenticate” в соответствии с определенной выше структурой, которая для Схемы дайджеста используется следующим образом:

challenge = “Digest” digest-challenge

digest-challenge = 1#( realm | [ domain ] | nonce | [ opaque ] |[ stale ] | [ algorithm ] | [ qop-options ] | [auth-param] )

domain = “domain” “=” <“> URI ( 1*SP URI ) <“>URI = absoluteURI | abs_pathnonce = “nonce” “=” nonce-valuenonce-value = quoted-stringopaque = “opaque” “=” quoted-stringstale = “stale” “=” ( “true” | “false” )algorithm = “algorithm” “=” ( “MD5” | “MD5-sess” | token )qop-options = “qop” “=” <“> 1#qop-value <“>qop-value = “auth” | “auth-int” | token

Смыслы значений директив заголовка ответа “WWW-Authenticate”, использованных выше, следующие:

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

2.2.1. Request-Digest

Если значение “qop” равно “auth” или “auth-int”:

request-digest = <"> < KD ( H(A1), unq(nonce-value)
                              ":" nc-value
                              ":" unq(cnonce-value)
                              ":" unq(qop-value)
                              ":" H(A2)
                          ) <">

Если директива “qop” отсутствует (эта конструкция предназначена для совместимости с RFC 2069):

request-digest = <"> < KD ( H(A1), unq(nonce-value) ":" H(A2) ) > <">

Ниже приведены определения для “А1” и “А2”.

2.2.2. A1

Если значение директивы “algorithm” равно «MD5» или не указано, то A1:

2.2.3. A2

Если значение директивы “qop” равно “auth” или не указано, то A2 – это:

A2 = Method ":" digest-uri-value

Если значение “qop” равно “auth-int”, то A2:

A2 = Method ":" digest-uri-value ":" H(entity-body)

3. Дайджест Операция

Получив заголовок “Authorization”, сервер может проверить его действительность путем поиска пароля, который соответствует представленному имени пользователя. Затем сервер должен выполнить ту же самую операцию дайджеста (например, MD5), которую выполняет клиент, и сравнить результат с заданным значением дайджеста запроса (request-digest).

10. Атаки по предварительно вычисленным словарям

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

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

Противодействие этой атаке заключается в том, чтобы клиенты были настроены так, чтобы требовать использования необязательной директивы «cnonce».

11. Групповые атаки методом грубой силы

С помощью дайджест-аутентификации MITM может выполнять выбранную атаку с открытым текстом и может собирать ответы от многих пользователей на один и тот же одноразовый номер. Затем он может найти все пароли в любом подмножестве пространства паролей, которое сгенерирует одну из пар “nonce/response” за один проход по этому пространству.

Это также сокращает время нахождения первого пароля на коэффициент, равный количеству собранных пар “nonce/response”. Такой поиск пространства паролей часто можно выполнять параллельно на многих машинах, и даже одна машина может очень быстро искать большие подмножества пространства паролей – существуют отчеты о поиске всех паролей с шестью или менее буквами в течение нескольких часов.

Противодействие этой атаке заключается в том, чтобы клиенты были настроены так, чтобы требовать использования необязательной директивы «cnonce».

12. Подмена поддельных серверов

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

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

13. Хранение паролей

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

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

С другой стороны, для получения пароля пользователя потребуется расшифровка или, что более вероятно, атака методом перебора. Это причина того, что область является частью переваренных данных, хранящихся в файле паролей. Это означает, что если один файл пароля аутентификации Digest скомпрометирован, он автоматически не скомпрометирует других с тем же именем пользователя и паролем (хотя он подвергает их атаке методом грубой силы “brute force”).

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

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

14. Резюме

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

В частности, структура одноразового номера (которая зависит от реализации сервера) может повлиять на простоту установки атаки воспроизведения. Целый ряд серверных опций является подходящим, поскольку, например, некоторые реализации могут быть готовы принять серверные накладные расходы одноразовых “nonce” или дайджестов, чтобы исключить возможность воспроизведения.

Суть в том, что * любая * совместимая реализация будет относительно слабой по криптографическим стандартам, но * любая * совместимая реализация будет намного превосходить базовую аутентификацию.

2. Аутентификация клиентов с использованием дайджест-аутентификации

Дайджест-аутентификация не обеспечивает надежного механизма аутентификации, например, по сравнению с механизмами на основе открытого ключа. Однако он значительно сильнее, чем (например) CRAM-MD5, который был предложен для использования с LDAP [10], POP и IMAP (см. RFC 2195 [9]). Он призван заменить гораздо более слабый и еще более опасный базовый механизм.

Digest Authentication не обеспечивает никакой защиты конфиденциальности, кроме защиты действительного пароля. Все остальные запросы и ответы доступны перехватчику.

Дайджест-аутентификация обеспечивает только ограниченную защиту целостности сообщений в любом направлении. Если используется механизм “qop=auth-int”, то те части сообщения, которые использовались при расчете значений директивы ответа в поле заголовка WWWAuthenticate и Authorization (см. Раздел 3.2 выше), защищены. Большинство полей заголовка и их значения могут быть изменены как часть атаки «человек посередине». (man-in-the-middle)

3. Ограниченные использование значений Nonce

Digest схема использует одноразовый номер (nonce), указанный сервером, чтобы инициировать генерацию значения дайджеста запроса (как указано в разделе 3.2.2.1 выше). Как показано в примере одноразового номера в разделе 3.2.1, сервер может создать одноразовый номер таким образом, чтобы его можно было использовать только от конкретного клиента, для конкретного ресурса, в течение ограниченного периода времени или количества использований или любого другого ограничения.

Это усиливает защиту, например, от атак воспроизведения (replay attacks) (см. 4.5). Однако следует отметить, что метод, выбранный для генерации и проверки одноразового номера, также влияет на производительность и ресурсы. Например, сервер может разрешить использование каждого одноразового значения только один раз, ведя запись о том, был ли возвращен каждый недавно выданный одноразовый номер и отправляя директиву “next-nonce” в поле заголовка “Authentication-Info” каждого ответа.

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

Аналогичным образом, включение специфичного для запроса элемента, такого как значение Etag для ресурса, ограничивает использование одноразового номера этой версией ресурса, а также предотвращает конвейерную обработку. Таким образом, это может быть полезно для методов с побочными эффектами, но неприемлемо для тех, которые этого не делают.

4. Сравнение дайджеста с базовой аутентификацией

И дайджест, и базовая аутентификация находятся на слабом конце спектра безопасности. Но сравнение между этими двумя пунктами указывает на полезность и даже необходимость замены Basic на Digest.

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

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

5. Повторные атаки

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

Таким образом, для некоторых целей необходимо защитить от повторных атак. Хорошая реализация дайджеста может сделать это различными способами. Созданное сервером значение «nonce» зависит от реализации, но если оно содержит дайджест IP-адреса клиента, метку времени, ETag ресурса и частный ключ сервера (private server key) (как рекомендовано выше), то атака воспроизведения не является простой.

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

Для приложений, в которых нельзя допустить возможность повторной атаки, сервер может использовать одноразовые значения nonce, которые не будут учитываться при повторном использовании. Это требует от сервера дополнительных затрат на запоминание того, какие значения nonce использовались до тех пор, пока не истечет временная метка nonce (и, следовательно, созданный с ее помощью дайджест), но это эффективно защищает от атак воспроизведения.

Реализация должна уделять особое внимание возможности повторных атак с запросами POST и PUT. Если сервер не использует одноразовые или иным образом ограниченные одноразовые номера и / или не настаивает на использовании защиты целостности “qop=auth-int”, злоумышленник может воспроизвести действительные учетные данные из успешного запроса с поддельными данными формы или другим телом сообщения.

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

7. Атаки онлайн-словаря

Если злоумышленник может подслушать, он может проверить любые подслушанные пары “nonce/response” против списка общих слов. Такой список обычно намного меньше, чем общее количество возможных паролей. Стоимость вычисления ответа для каждого пароля в списке оплачивается один раз за каждый вызов.

Сервер может смягчить эту атаку, не позволяя пользователям выбирать пароли в словаре.

8. Человек посередине

Как базовая, так и дайджест-проверка подлинности уязвимы для атак «человек посередине» (MITM), например, со стороны враждебного или скомпрометированного прокси-сервера. Ясно, что это представляет все проблемы подслушивания. Но это также предлагает некоторые дополнительные возможности для атакующего.

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

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

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

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

9. Выбранные атаки открытым текстом

С помощью дайджест-аутентификации MITM или злонамеренный сервер могут произвольно выбирать одноразовый номер (nonce), который клиент будет использовать для вычисления ответа. Это называется атакой “chosen plaintext” (выбранным открытым текстом). Известно, что возможность выбора одноразового номера значительно облегчает криптоанализ (cryptanalysis) [8].

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

Противодействие этой атаке заключается в том, что клиенты должны быть сконфигурированы так, чтобы требовать использования необязательной директивы “cnonce”; это позволяет клиенту изменять входные данные для хэша способом, не выбранным злоумышленником.

Пример реализации

Следующий код реализует вычисления H (A1), H (A2), запроса-дайджеста и ответа-дайджеста, а также тестовую программу, которая вычисляет значения, использованные в примере из раздела 3.5. Он использует реализацию MD5 из RFC 1321.

Файл “digcalc.h”:

#define HASHLEN 16typedef char HASH[HASHLEN];#define HASHHEXLEN 32typedef char HASHHEX[HASHHEXLEN 1];#define IN#define OUT

Благодарности

Эрик У. Синк (Eric W. Sink) из AbiSource, Inc., был одним из авторов, прежде чем спецификация претерпела существенные изменения.

В дополнение к авторам ценную дискуссию, способствующую созданию этого документа, пришли Питер Дж. Черчард (Peter J. Churchyard), Нед Фрид (Ned Freed) и Дэвид М. Кристол (David M. Kristol).

Джим Геттис (Jim Gettys) и Ларри Масинтер (Larry Masinter) редактировали этот документ для обновления.

Domain – домен

Цитированный разделенный пробелами список URI, как указано в RFC XURI [7], которые определяют пространство защиты (protection space). Если URI является “abs_path”, он относится к каноническому корневому URL (см. Раздел 1.2 выше) сервера, к которому осуществляется доступ.

Абсолютный URI (absoluteURI) в этом списке может относиться к серверу, отличному от того, к которому осуществляется доступ. Клиент может использовать этот список, чтобы определить набор URI, для которых может быть отправлена одна и та же информация аутентификации:

любой URI, который имеет URI в этом списке в качестве префикса (после того, как оба были сделаны абсолютными), можно считать находящимся в одном и том же защитном пространстве. Если эта директива (domain) опущена или ее значение пусто, клиент должен предположить, что пространство защиты состоит из всех URI на отвечающем сервере.

“nonce” – это указанная сервером строка данных, которая должна генерироваться уникальным образом каждый раз при получении ответа 401. Рекомендуется, чтобы строкой nonce были base64 или шестнадцатеричные данные. В частности, поскольку строка nonce передается в строках заголовка в виде строки в кавычках, символ двойной кавычки не допускается.

Содержимое одноразового номера зависит от реализации. Качество реализации зависит от удачного выбора. Одноразовый номер может, например, быть сконструирован как кодировка base 64

time-stamp H(time-stamp “:” ETag “:” private-key)

Message-qop

Директива “message-qop” указывает параметры «качества защиты» (“quality of protection”), применяемые к ответу сервера. Значение «auth» указывает на аутентификацию; значение «auth-int» указывает на аутентификацию с защитой целостности. Сервер ДОЛЖЕН использовать в ответе то же значение для директивы “message-qop”, которое было отправлено клиентом в соответствующем запросе.

Необязательный дайджест ответа в директиве “response-auth” поддерживает взаимную аутентификацию – сервер подтверждает, что знает секрет пользователя, и с помощью (qop=auth-int) также обеспечивает ограниченную защиту целостности ответа. Значение “response-digest” рассчитывается так же, как и для “request-digest” в заголовке авторизации, за исключением того, что если “qop=auth” или не указано в заголовке авторизации для запроса, A2

A2 = “:” digest-uri-value

и если “qop=auth-int”, то A2

A2 = “:” digest-uri-value “:” H(entity-body)

где “digest-uri-value” – это значение директивы “uri” в заголовке авторизации в запросе. “Cnonce-value” и “nc-value” ДОЛЖНЫ быть теми для запроса клиента, на который это сообщение является ответом. Директивы «response-auth», «cnonce» и «nonce-count» ДОЛЖНЫ БЫТЬ присутствовать, если указано “qop=auth” или “qop=auth-int”.

Nextnonce

Значение директивы “nextnonce” – это тот раз, когда сервер желает, чтобы клиент использовал его для будущего ответа аутентификации. Сервер может отправить заголовок Authentication-Info с полем nextnonce в качестве средства реализации одноразовых или иным образом изменяющихся одноразовых номеров (nonces).

Если поле nextnonce присутствует, клиент ДОЛЖЕН использовать его при создании заголовка Authorization для своего следующего запроса. Невыполнение этого требования клиентом может привести к запросу на повторную аутентификацию с сервера с помощью «stale=TRUE».

Реализации сервера должны тщательно учитывать последствия использования этого механизма для производительности; конвейерные запросы будут невозможны, если каждый ответ содержит директиву nextnonce, которая должна использоваться при следующем запросе, полученном сервером.

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

Авторизация через .htaccess

function bcrypt($password)
{
	$rounds = 12;
	$salt = sprintf('$2a$d$', $rounds) . substr(str_replace(' ', '.', base64_encode(pack('N4', mt_rand(), mt_rand(), mt_rand(), mt_rand()))), 0, 22);
	return crypt($password, $salt);
}

echo bcrypt('123456'); // $2a$12$dMHIiiPfeSMxqj3/Wt1.z.Mo7NPza1x/WANl7hDXZJzxxKKorz5um

function crypt_apr1_md5($password)
{
	$salt = substr(str_shuffle('abcdefghijklmnopqrstuvwxyz0123456789'), 0, 8);
	$len = strlen($password);
	$text = $password . '$apr1$' . $salt;
	$bin = pack('H32', md5($password . $salt . $password));
	for($i = $len; $i > 0; $i -= 16) {
		$text .= substr($bin, 0, min(16, $i));
	}
	for($i = $len; $i > 0; $i >>= 1) {
		$text .= ($i & 1) ? chr(0) : $password{0};
	}
	$bin = pack('H32', md5($text));
	for($i = 0; $i < 1000; $i  ) {
		$new = ($i & 1) ? $password : $bin;
		if ($i % 3) {
			$new .= $salt;
		}
		if ($i % 7) {
			$new .= $password;
		}
		$new .= ($i & 1) ? $bin : $password;
		$bin = pack('H32', md5($new));
	}
   
	$tmp = '';
	for ($i = 0; $i < 5; $i  ) {
		$k = $i   6;
		$j = $i   12;
		if ($j == 16) $j = 5;
		$tmp = $bin[$i] . $bin[$k] . $bin[$j] . $tmp;
	}
	$tmp = chr(0) . chr(0) . $bin[11] . $tmp;
	$tmp = strtr(
		strrev(substr(base64_encode($tmp), 2)),
		'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789 /',
		'./0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz'
	);
 
	return '$apr1$' . $salt . '$' . $tmp;
}

echo crypt_apr1_md5('123456'); // $apr1$h9j4azoy$unmKNqjZlRfZv5xRetm9p1

Группы

Если к защищенной директории необходимо предоставить доступ множеству людей, удобнее всего разделить их на группы, в соответствии с которыми будет предоставлен доступ.

Дата создания документа

Июнь 1999 года

Статус этой заметки

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

Распространение этой заметки не ограничено.