RFC 4226

RFC 4226 (англ. Request for Comments 4226, «HOTP: An HMAC-Based One-Time Password Algorithm») — это стандарт Интернета, опубликованный в декабре 2005 года, который определяет алгоритм генерации одноразовых паролей на основе HMAC (HOTP). Данный алгоритм является основой для систем двухфакторной аутентификации (2FA), используемых для повышения безопасности доступа к информационным системам, веб-сервисам и физическим устройствам. RFC 4226 был разработан рабочей группой OATH (Open AuTHentication) и является ключевым документом, описывающим метод создания динамических кодов, действительных в течение одного сеанса или транзакции.

История и предпосылки создания

К началу 2000-х годов стало очевидным, что статические пароли, используемые для аутентификации пользователей, обладают существенными недостатками: они могут быть перехвачены, угаданы или украдены с помощью фишинговых атак. Потребность в более надёжных методах аутентификации привела к развитию концепции одноразовых паролей (OTP). В 2004 году организация OATH, объединяющая производителей оборудования, программного обеспечения и поставщиков услуг, начала работу над открытым стандартом для генерации OTP. Результатом этой работы стал RFC 4226, который был принят IETF (Internet Engineering Task Force) в качестве предложения по стандартизации (Proposed Standard). Алгоритм HOTP был основан на более ранних разработках, в частности на идеях, заложенных в спецификации HMAC (RFC 2104) и криптографической хеш-функции SHA-1.

Основные принципы работы алгоритма HOTP

Алгоритм HOTP генерирует одноразовый пароль на основе двух входных данных: секретного ключа (K), который известен только серверу и клиенту, и счётчика (C), представляющего собой 8-байтовое целое число без знака. Счётчик увеличивается на единицу после каждой успешной или неудачной попытки аутентификации, обеспечивая уникальность каждого пароля.

Этапы генерации пароля

1. Вычисление HMAC-SHA-1: На секретном ключе K и текущем значении счётчика C вычисляется HMAC с использованием хеш-функции SHA-1. Результатом является 160-битное (20-байтовое) значение HMAC.
2. Динамическое усечение (Dynamic Truncation): Из полученного 20-байтового значения извлекается 31-битное целое число. Для этого используется младшие 4 бита последнего байта HMAC в качестве индекса (offset). Начиная с этого индекса, извлекаются 4 байта (32 бита), при этом старший бит (31-й) обнуляется, чтобы результат был положительным целым числом.
3. Вычисление HOTP: Полученное 31-битное число делится по модулю 10^D, где D — требуемая длина пароля (обычно 6, 7 или 8 цифр). Результат деления и есть одноразовый пароль. Например, для 6-значного пароля: HOTP = (DT % 10^6), где DT — результат динамического усечения.

Формула

Формально алгоритм описывается следующим образом: HOTP(K, C) = Truncate(HMAC-SHA-1(K, C)) mod 10^D

Где:

• K — секретный ключ (длина не менее 128 бит, рекомендуется 160 бит);
• C — 8-байтовый счётчик (целое число);
• Truncate — функция динамического усечения;
• D — количество цифр в пароле (по умолчанию 6).

Параметры и характеристики

RFC 4226 определяет несколько ключевых параметров, которые могут быть настроены в зависимости от требований безопасности и удобства использования.

Длина пароля (D)

Наиболее распространённой длиной является 6 цифр (D=6). Это обеспечивает 1 000 000 возможных комбинаций, что достаточно для большинства применений. Допускается использование 7 или 8 цифр, однако это увеличивает время ввода пароля пользователем.

Счётчик (C)

Счётчик является критическим элементом алгоритма. Он синхронизируется между клиентом и сервером. Клиент увеличивает счётчик после каждой попытки генерации пароля, а сервер — после успешной аутентификации. Для учёта возможных ошибок (например, генерация пароля, который не был использован) RFC 4226 рекомендует использовать механизм «окна» (look-ahead window). Сервер может проверять не только текущее значение счётчика, но и несколько последующих (например, до 100), что позволяет компенсировать потерю синхронизации.

Секретный ключ (K)

Ключ должен быть случайным и генерироваться с использованием криптостойкого генератора псевдослучайных чисел. Рекомендуемая длина — не менее 128 бит (16 байт), а оптимальная — 160 бит (20 байт), что соответствует длине выхода SHA-1. Ключ обычно передаётся на клиентское устройство (например, токен или смартфон) в зашифрованном виде или через защищённый канал (например, QR-код при настройке приложения-аутентификатора).

Применение и реализация

Алгоритм HOTP нашёл широкое применение в системах двухфакторной аутентификации (2FA). Наиболее известные реализации:

• Аппаратные токены: Устройства (например, RSA SecurID, YubiKey), которые генерируют одноразовые пароли по нажатию кнопки. Счётчик в таких токенах увеличивается при каждой генерации.
• Программные аутентификаторы: Приложения на смартфонах (Google Authenticator, Authy, Microsoft Authenticator), которые генерируют коды на основе HOTP или его варианта TOTP (RFC 6238). В случае HOTP пользователь обычно нажимает кнопку «Получить код», что увеличивает счётчик.
• Веб-сервисы и корпоративные системы: Многие онлайн-платформы (банки, социальные сети, облачные сервисы) используют HOTP (или TOTP) в качестве второго фактора аутентификации.
• Финансовые транзакции: Используется для подтверждения платежей и переводов, где каждый код действителен только для одной операции.

Пример реализации на серверной стороне

Сервер хранит для каждого пользователя его секретный ключ и текущее значение счётчика. При попытке аутентификации сервер:

1. Получает от пользователя одноразовый пароль.
2. Вычисляет HOTP для текущего счётчика и нескольких последующих (в пределах окна).
3. Сравнивает полученные значения с введённым паролем.
4. Если совпадение найдено, сервер обновляет счётчик до значения, при котором пароль был сгенерирован, и аутентификация считается успешной.

Критика и ограничения

Несмотря на широкое распространение, алгоритм HOTP имеет ряд недостатков:

• Уязвимость к атакам с предсказанием счётчика: Если злоумышленник получит доступ к секретному ключу, он сможет генерировать все будущие пароли, зная текущее значение счётчика.
• Проблема синхронизации: Если пользователь генерирует несколько паролей подряд без их использования (например, по ошибке нажав кнопку токена), счётчик на клиенте и сервере рассинхронизируется. Механизм окна решает эту проблему лишь частично.
• Зависимость от HMAC-SHA-1: Алгоритм использует SHA-1, который на момент создания считался безопасным, но к концу 2010-х годов были обнаружены атаки на коллизии (например, SHAttered). Однако в контексте HOTP атаки на коллизии не представляют прямой угрозы, так как злоумышленнику нужно найти не коллизию, а предобраз (preimage) для получения ключа.
• Ограниченная длина пароля: 6-значный код (1 миллион комбинаций) может быть угадан методом перебора, если не реализованы механизмы блокировки после нескольких неудачных попыток.

Варианты и развитие

Наиболее известным развитием HOTP является алгоритм TOTP (Time-Based One-Time Password, RFC 6238), опубликованный в 2011 году. В TOTP вместо счётчика используется текущее время, разделённое на интервал (обычно 30 секунд). Это устраняет проблему синхронизации счётчика, но требует точной синхронизации часов на клиенте и сервере. TOTP стал более популярным для приложений-аутентификаторов, так как не требует нажатия кнопки для генерации кода.

Источники

• RFC 4226 — HOTP: An HMAC-Based One-Time Password Algorithm (December 2005).
• M’Raihi, D., Bellare, M., Hoornaert, F., Naccache, D., and O. Ranen. HOTP: An HMAC-Based One-Time Password Algorithm. IETF, 2005.
• RFC 6238 — TOTP: Time-Based One-Time Password Algorithm (May 2011).
• Krawczyk, H., Bellare, M., and R. Canetti. HMAC: Keyed-Hashing for Message Authentication (RFC 2104, February 1997).
• Open AuTHentication (OATH) Reference Architecture.