Кратко

  • nc — это число запросов, которые клиент, по его утверждению, отправил с указанным в запросе серверным nonce. Для обнаружения повторного значения серверу нужно хранить соответствующее состояние.
  • Digest связывает счётчик с материалом, производным от учётных данных, с nonce и выбранными элементами HTTP. Глобального ID, прикладного разрешения или записи об исполнении из этого не возникает.
  • Для значимого действия отдельно нужны устойчивая идентичность операции и проверяемый результат. Корректная аутентификация повтора не доказывает, что предыдущая попытка не дала эффекта.

Последовательность, похожая на чужой журнал

Первый запрос с данным nonce несёт nc=00000001, затем клиент увеличивает восьмизначное шестнадцатеричное значение. Если сервер хранит собственную копию счётчика и снова видит то же значение в отслеживаемом контексте, он может распознать replay. Полезность здесь конкретна: ожидаемое продвижение повторилось.

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

После ротации nonce ряд начинается заново. У другого клиента, realm или protection space будет собственный ряд. Возврат к единице означает новый контекст аутентификации, а не обнуление деловой истории. Поэтому nc задаёт координату внутри протокольного обмена, но не место транзакции среди всех действий сервиса.

Даже для replay одного числа мало. Без server nonce, client nonce, личности, realm и решения сервера восемь знаков в журнале почти лишены доказательной силы. Полный набор объяснит аутентификацию, но всё равно ничего не скажет о commit приложения.

Смысл числу придаёт память сервера

RFC 7616 прямо связывает выявление повтора с собственной копией счётчика на сервере. Клиентское значение не доказывает себя само. Его нужно сопоставить с состоянием и политикой выпуска nonce.

Nonce непрозрачен для клиента, а его устройство зависит от реализации. Сервер может ограничить срок, ресурс, клиента, число применений или иное условие. Одноразовый nonce, расход которого запоминается, защищает даже от немедленного replay, но требует состояния и мешает pipelining. Более долгоживущий nonce вместе с nc позволяет нескольким запросам использовать один challenge, сохраняя значительную часть защиты.

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

Что именно связано вычислением Digest

При qop в response входят материал от пароля, серверный nonce, nc, client nonce, значение qop и хеш A2. Для qop=auth A2 состоит из HTTP-метода и URI запроса. Для qop=auth-int добавляется хеш entity body. Сервер тем самым проверяет знание секрета и может обнаружить некоторые повторы или изменения.

Охват ограничен. Даже при auth-int большинство HTTP-заголовков остаётся вне контроля целостности; RFC предупреждает об их изменении посредником. Digest также не обеспечивает конфиденциальность остального обмена и рекомендуется поверх HTTPS.

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

Авторство тоже требует точности. Rifaat Shekh-Yusef — указанный редактор и соавтор согласованного IETF документа, но не единственный изобретатель механизма. Nonce count уже был в RFC 2617. RFC 7616 сохранил его, добавив SHA-256, SHA-512/256, согласование алгоритма, обновлённые требования qop, userhash и более ясный разбор рисков. При этом документ подчёркивает: смена алгоритма не устраняет словарные атаки на запоминаемые пароли.

Ответ сервера подтверждает не тот результат

В Authentication-Info сервер может вернуть rspauth, а также cnonce и nc соответствующего запроса. Так он демонстрирует знание пользовательского секрета; auth-int добавляет ограниченную целостность ответа. Это полезная взаимная аутентификация.

Она не является квитанцией приложения. Эти поля не именуют платёж, задачу, commit, откат или результат, который можно запросить позже. Сервер может проверить Digest и передать работу worker, worker успеет записать изменение, а HTTP-ответ потеряется. Клиент получит новый nonce и корректно повторит запрос. Безошибочность двух Digest-обменов не исключает двойного прикладного эффекта.

Недостающий контроль создаётся на другом уровне. Idempotency key связывает попытки с одной устойчивой операцией до возникновения эффекта. Запрос результата по этому ключу снимает неопределённость после timeout. RFC 7616 таких механизмов не определяет, и расширять ради них смысл nc нельзя.

Пять записей вместо одного успеха

Для последствия важны как минимум пять отдельных фактов: аутентификация прошла; replay policy допустила контекст nonce; приложение разрешило действие; действию присвоена устойчивая идентичность; postcondition зафиксирована. Иногда шестым фактом становится доставка ответа клиенту.

Точное применение nonce count сохраняет его пользу. Нужно защищать серверное состояние, выбирать ограниченные nonce по уровню риска, осознанно задавать qop и использовать HTTPS. Но затем вывод должен остановиться. Счётчик аутентификации не наблюдает прикладной журнал и не способен его заменить.

Источники