Кратко

  • RFC 2069 заменил передачу открытого пароля Basic на challenge-response, однако серверный H(A1) оставался эквивалентом пароля в пределах realm и требовал такой же защиты.
  • Базовый response связывал секрет с nonce, методом HTTP и URI запроса; он не шифровал содержание, не охватывал автоматически всё сообщение и не подтверждал намерение, полномочие или результат.
  • Адресно-временной nonce можно проверять без состояния и тем самым ограничивать окно replay. Чтобы доказать отсутствие прежнего использования, серверу приходилось помнить принятые значения до истечения срока.

Две успешные проверки — один неразрешённый вопрос

В Basic из RFC 1945 имя и пароль передавались в Base64. Это было кодирование, а не шифрование: наблюдатель получал повторно используемый пароль. RFC 2069, опубликованный в январе 1997 года, предложил серверный nonce и вычисляемый клиентом response. Пароль больше не шёл по сети открытым. Контекстом служил первый HTTP/1.1 в RFC 2068.

Спецификация не называла эту перемену полной защитой. Digest описан как слабый метод доступа; он не шифровал содержание, не определял первоначальный безопасный обмен паролем и оставлял риски посредника, поддельного сервера, словарного перебора и replay. Карточка RFC 2069 подтверждает место документа в истории стандартов, но не внедрение в конкретном продукте.

Формула перечисляла свои полномочия

Единственным конкретным алгоритмом был MD5 из RFC 1321. Основная конструкция выглядела так:

A1 = username : realm : password
A2 = Method : request-URI
response = KD(H(A1), nonce : H(A2))

Realm входил в секретный материал, метод и URI — в A2, nonce — в окончательный вызов. Совпадение означало: предъявитель располагает материалом, позволяющим построить корректный ответ для данного пользователя, realm, вызова, метода и URI.

Даже URI требовал отдельной проверки. Сервер обязан был убедиться, что значение uri в Authorization обозначает действительно обслуживаемый ресурс, поскольку промежуточный proxy мог изменить request line. Арифметическое совпадение не разрешало прикреплять доказательство к другой цели.

Остальные заголовки, путь передачи, ответ сервера и прикладное решение в базовую формулу не входили. Она не шифровала body, не устанавливала личность человека, не фиксировала согласие, не выдавала право на действие и не подтверждала commit. Для POST/PUT RFC 2069 предложил отдельный необязательный digest body и выбранных метаданных. Наличие дополнения показывает, что основной response не подписывал всё HTTP-сообщение.

Файл без открытых паролей всё ещё открывал realm

Сервер мог проверять запрос, имея username и H(A1), без открытого пароля. Однако раздел о хранении прямо говорил: похитивший такой файл получает немедленный доступ к документам его realm, не восстанавливая пароль. Поэтому файл следует охранять так, как если бы в нём лежали незашифрованные пароли.

Эквивалентность ограничена realm. Поскольку строка realm участвует в A1, украденное значение не обязано работать в другом realm с теми же пользовательскими данными. Но в своём пространстве H(A1) — исполнимый секрет, а не безвредный отпечаток. Слабый пароль вдобавок можно подбирать офлайн.

Отсюда меняется смысл резервирования. Каждая backup-копия или replica H(A1) улучшает восстановление и одновременно добавляет место, из которого можно произвести принимаемый response.

Самопроверяемый nonce не помнит прошлое

RFC 2069 рекомендовал включать в nonce примерно такие данные:

H(client-IP : timestamp : server-private-key)

Узел мог пересчитать значение, проверить адрес и срок, не записывая каждый выданный вызов. Это удобно для масштабирования. Но проверка отвечает «nonce создан сервером и ещё действителен», а не «этот Authorization никогда не принимался».

Для простого GET replay считался обычно малополезным: URI связан, а наблюдатель уже видел документ. Спецификация всё же отметила GET с побочным действием и особо предупредила о POST/PUT, повтор которых способен внести ложные данные или файл.

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

Преемники уточнили границу

RFC 2617 сменил 2069, что прямо записано в его официальной карточке. Он добавил qop, клиентский cnonce и счётчик nc. Сервер, сохраняющий собственное значение счётчика, может распознать повтор одинакового nc. Режим qop=auth-int добавляет hash body в A2. Без qop для совместимости остаётся формула RFC 2069; значит, эти средства нельзя приписывать базовому протоколу 1997 года.

RFC 7616 и его карточка добавили SHA-256 и SHA-512/256, оставив MD5 лишь как нерекомендуемую совместимость. Предупреждение о H(A1) сохранилось: украденный verifier сразу действует в realm. Документ также подчёркивает, что смена алгоритма не спасает человеческий слабый пароль, и рекомендует HTTPS.

Современная семантика RFC 9110 помогает удержать ещё одну границу: принятые credentials могут быть входом для authorization, но не являются самим решением и его эффектом.

Как читать спорный журнал

Из успешного Digest для POST /settle следует лишь, что один узел принял соотношение между секретом, nonce, методом и URI. Для разбора нужны алгоритм, qop, охват body, replay-state, узел проверки, principal, действовавшая политика, transaction ID и итоговый commit. Без них нельзя вывести ни намерение, ни однократность.

Running-Code Primacy Лу Хэна требует видеть реально исполняемую проверку, а не превращать публикацию в факт внедрения. Minimum Initial Specification отделяет общую детерминированную формулу от локальных решений участников. Срок nonce, бюджет состояния, хранение verifier и authorization принадлежат операторам.

Его заметка о Reality Layers не позволяет одному символу присвоить последствия следующего уровня. Совпадение hash — свидетельство вычисления. Намерение и результат требуют свидетельства систем, которые их исполняли.

Источники