Этот недостаток роднит digest- и basic- механизмы. Он, очевидно, связан с самой природой протокола HTTP, для которого не существует понятия «сессия».

Теперь понятно, что digest-авторизация, как и basic-авторизация, не в состоянии создать ощутимые препятствия для грубого перебора паролей. Справедливости ради следует отметить, что в полном описании digest-процедуры предусмотрены средства (дополнительные переменные и алгоритмы работы с ними), позволяющие детектировать подобную атаку и создать ощутимые препятствия для её осуществления. Но мне не известно ни одной программы, в которой эти средства были бы реализованы в полной мере. (Обсуждению реализаций посвящена следующая часть статьи.)

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

Корни этой проблемы тоже кроются в протоколе HTTP, и, конечно, проблема пропадёт автоматически, если воспользоваться протоколом SHTTP, защищающим все передаваемые данные. Но это уже, согласитесь, несколько другой протокол.

Но (и это в-третьих) самый интересный вопрос: а защищён ли на самом деле пароль? Ответ на него не так прост.

Казалось бы, что может быть надёжнее MD5-хэширования? Но давайте приглядимся. Злоумышленник может перехватить заголовок – это факт. Нужен ли тогда ему пароль? Очевидно – нет! Достаточно включить в запросы перехваченный заголовок Authorization и – о чудо! – вы получаете доступ к секретной информации и не зная пароля. Конечно, Internet Explorer не поможет произвести подобный взлом, но тот, кто смог перехватить ваш трафик, сумеет найти подходящий инструмент.

Безусловно, большой ложкой дёгтя для злоумышленника будет то, что при хешировании пароля используется и URI документа. То есть для разных документов переменная response должна иметь разные значения, и вычислить их можно, только зная пароль. Так что один заголовок может открыть доступ только к одному документу. (Напомню, что при basic-авторизации один перехваченный заголовок открывает полный доступ ко всей закрытой области.) Но один документ – тоже очень немало, если это лента новостей или нечто в этом роде. Кроме того, можно собрать коллекцию заголовков – по одному на каждый документ.

Так что же получается, что защита пароля на самом деле – фикция? Не совсем. Модуль mod_auth_digest предоставляет множество новых конфигурационных директив (мы ещё вернёмся к некоторым из них), среди которых есть одна, способная помочь в решении обозначенной проблемы.

Речь идёт о директиве AuthDigestNonceLifetime. Её единственный аргумент задаёт время, в течение которого параметр nonce остаётся актуальным. По истечении этого времени информация, передаваемая в заголовке Authorization, «устаревает», и клиенту приходится авторизоваться снова. Это происходит автоматически по обычному сценарию. Просто на очередной запрос браузер получает ответ 401, в котором указан новый параметр nonce, но уже известная браузеру зона. Поэтому браузер вычисляет новый параметр response (по новому nonce и уже известному паролю) и формирует новый запрос с «правильным» заголовком Authorization, не причиняя пользователю никаких неудобств.