Дополнительное усиление защиты создаётся тем, что сервер и клиент ведут счёт соединениям и используют этот счётчик при вычислении хэш-суммы response. То есть значение параметра response при каждом новом соединении оказывается новым. За более подробной информацией вы можете обратиться к третьей главе RFC-2617, параметры nc, state и другие; здесь же мы не будем чрезмерно вдаваться в детали. Главный вывод таков: использование счётчиков делает перехват заголовков практически бесполезным; но используются счётчики только более современным модулем mod_auth_digest, модуль digest_module не способен работать с nc и сопутствующими параметрами.

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

Готовый рецепт взлома пароля

В рамках одной статьи трудно осветить все степени защиты, которые обеспечивает digest-авторизация (к сожалению, далеко не все из них реализованы на практике). Так мы даже не коснулись ещё одного HTTP-заголовка Authentical-Info, который не является обязательным (и используется редко), но позволяет защититься от многих типов атак. Мы не рассмотрели конфигурационную директиву AuthDigestRealmSeed, позволяющую немного усилить защиту при использовании mod_digest, но практически бесполезную для mod_auth_digest, который предоставляет гораздо более мощные средства. Эти и многие другие детали и тонкости, устаревшие или не имеющие принципиального значения, мы оставим специалистам. А здесь отметим, что если вы базируетесь только на материале этой статьи, то не факт, что атака, придуманная вами, будет успешной.

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

Она базируется на перехвате и подмене трафика. Опытному программисту, имеющему под рукой исходный код Apache, потребуется несколько часов, чтобы написать специальный прокси-сервер, который будет делать следующее: получив от сервера ответ 401 с требованием авторизоваться по digest-схеме, прокси отправляет клиенту изменённый ответ 401, требующий basic-авторизации; клиент авторизуется по basic-схеме и отправляет хозяину прокси-сервера имя и пароль в открытом виде (как того требует basic-процедура); всё – злоумышленник получил, что хотел. В принципе, зная имя и пароль, прокси-сервер может создать легальный digest-запрос для сервера и далее поддерживать общение клиента и сервера, оставаясь полностью прозрачным.

Возможность такой атаки, казалось бы, сводит на нет все преимущества digest-схемы, но на самом деле подобным атакам в той или иной мере подвержены все системы защиты. Злоумышленник может подменить программу login, может прослушивать клавиатуру и прочее. Этот сценарий атаки (MITM – man in the middle) – один из самых древних и универсальных. Он с успехом применялся задолго до появления вычислительной техники: от радиоперехвата до подделки берестяных грамот («и в суму его пустую суют грамоту другую» А.С. Пушкин). Совсем неудивительно, что этот тип атаки применим и в нашем случае.