Кратко

  • RFC 1938 принимал x, если H(x) совпадало с сохранённым проверочным значением, а затем сохранял сам x: успех сдвигал одностороннюю цепочку назад.
  • Однократность требовала атомарно объединить сравнение с обновлением, не допустить двух конкурентных успехов и заранее управлять исчерпанием и переинициализацией.
  • Секретная фраза не передавалась по сети, однако последующая сессия не шифровалась и активные атаки в целом не устранялись; HOTP и TOTP выбрали иные движущиеся состояния.

Успех меняет критерий

Две побитно одинаковые копии ответа могут иметь разный результат, если приходят одна за другой. По RFC 1938 сервер вычисляет H(x) для присланного x и сравнивает с сохранённым верификатором. При совпадении x принимается, после чего становится новым верификатором. Повторный x ведёт уже к старому ориентиру и больше не удовлетворяет текущему состоянию.

Запись RFC Editor датирует Proposed Standard Н. Халлера и К. Метца маем 1996 года и отмечает его замену документом RFC 2289. Статус задаёт нормативную хронологию. Но исторический смысл механизма в другом: аутентификация становится общей операцией изменения состояния.

Генератор соединяет секретную парольную фразу с несекретным seed и многократно применяет одностороннюю функцию. При глубине N первым используется H^N(S), затем H^(N-1)(S). Сервер хранит не фразу, а последний 64-битный верификатор и позицию последовательности. Из известного звена можно двигаться к уже израсходованным значениям, но не вычислить следующее ожидаемое.

Предшественником был Bellcore S/KEY, описанный в RFC 1760. Он решал узкую практическую задачу: пассивно перехваченный многоразовый пароль открывает будущие входы. Перехваченный элемент цепочки после законного продвижения терял ценность.

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

Шесть слов — это форма ввода

Challenge сообщал алгоритм, номер последовательности и seed, например otp-md5 487 dog2. Поддержка MD5 была обязательной, SHA — рекомендуемой, MD4 — допустимой. Обе стороны должны были совпасть в выборе, а слабейший разрешённый алгоритм мог ограничить всю систему.

Для ручного ввода 64 бита кодировались шестью словами из словаря на 2048 позиций. Каждое слово несло 11 бит, всего 66; дополнительные два бита служили проверкой некоторых ошибок ввода и декодирования. Это не второй фактор и не самостоятельная криптографическая подпись. Смысл слов также не добавлял секретности.

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

Гонку не решает хеш

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

Гонка возникает и между серверными процессами. Если оба прочитали старый верификатор, приняли x и открыли сессии до фиксации нового значения, один расходуемый ответ дал два успеха. Криптография верна, транзакция — нет. Сравнение и продвижение должны быть атомарными либо эквивалентно сериализованными.

Цепочка конечна. Номер последовательности показывает оставшийся запас. При переинициализации нужно сменить seed или парольную фразу; повтор обоих воспроизведёт потенциально наблюдавшиеся значения. Передача секретной фразы открытым текстом ради ремонта уничтожает исходную защиту.

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

Преемник сохранил границу

Карточка RFC 2289 указывает Proposed Standard февраля 1998 года как замену. Текст RFC 2289 сохраняет нисходящую цепочку, добавляет тестовые векторы и уточняет эксплуатационные рекомендации. Совет применять IPsec против перехвата TCP-соединения подчёркивает предел: валидный OTP не защищает автоматически последующий канал.

Поздние стандарты двигали другое состояние. HOTP использует общий секрет и растущий счётчик; проверяющая сторона может искать вперёд в окне синхронизации и продвигается после успеха. TOTP делает фактором времени шаг HOTP и запрещает повторно принимать уже успешный OTP в том же интервале. Это полезное сравнение, но не доказательство происхождения от S/KEY.

Во всех случаях одного вопроса «код совпал?» недостаточно. Нужно определить актуальное состояние, допустимую окрестность, расход после успеха и способ согласовать историю между экземплярами.

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

Механизм под названием

Идея Heng Lu о первенстве работающего кода превращает слово «один» в проверяемое требование. Только поведение при сбое, репликации и восстановлении показывает, не создают ли процессы две истории из одного ответа.

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

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

Главный урок RFC 1938: успешное доказательство способно изменить мир, в котором будут оценивать следующее. Тогда аутентификация — не чтение факта, а запись, требующая владельца, порядка и памяти.

Источники

  1. RFC Editor — текущая запись RFC 1938
  2. RFC 1938 — A One-Time Password System
  3. RFC 1760 — The S/KEY One-Time Password System
  4. RFC Editor — текущая запись RFC 2289
  5. RFC 2289 — A One-Time Password System
  6. RFC 4226 — HOTP
  7. RFC 6238 — TOTP
  8. Heng Lu — Running-Code Primacy
  9. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  10. Heng Lu — On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile