HOTP ( англ. HMAC-Based One-Time Password Algorithm ) — алгоритм защищённой аутентификации с использованием одноразового пароля (One Time Password, OTP). Основан на HMAC (SHA-1). Является алгоритмом односторонней аутентификации, а именно: сервер производит аутентификацию клиента .

В качестве параметра, отвечающего за динамику генерации паролей, используется событие, то есть сам факт генерации : каждый раз при создании нового пароля счётчик событий увеличивает своё значение на единицу, и именно это монотонное возрастающее значение используется как основной параметр алгоритма. Вторым параметром для расчёта одноразовых паролей является симметричный ключ, который должен быть уникальным для каждого генератора (клиента) и закрытым от всех, кроме сервера и самого генератора (клиента).

История

Алгоритм впервые формально описан командой IETF в декабре 2005. Он стал первым реально успешным проектом Initiative for Open Authentication ( ). Алгоритмы генерации одноразовых паролей получили в это время широкую популярность в связи с резким развитием мобильной индустрии. Требовался надёжный алгоритм, простой в плане реализации.

В 2008 году HOTP подарил жизнь более сильному алгоритму Time-based One-time Password Algorithm (TOTP), который во многом наследует черты родителя. В сентябре 2010 на основе TOTP был разработан мощный алгоритм аутентификации OATH Challenge-Response Algorithm ( OCRA ).

Алгоритм HOTP также внёс инновации в технологию генерации одноразовых паролей. Стойкая по тем временам хеш-функция SHA-1 сочеталась с нетривиальным решением наличия счётчика событий. Эти черты подняли HOTP на один уровень с такими проверенными временем алгоритмами, как S/KEY .

Счетчики в HOTP и TOTP

Основным отличием между двумя алгоритмами является генерация пароля на основе метки времени, которую использует в качестве параметра TOTP -алгоритм. При этом используется не точное значение времени, а текущий интервал, границы которого были установлены заранее (например, 30 секунд)

HOTP генерирует ключ на основе разделяемого секрета и не зависящего от времени счётчика. Модель этого алгоритма основана на событиях — например, каждый раз, когда генерируется очередной одноразовый пароль, счётчик будет увеличиваться. Следовательно, сгенерированные впоследствии пароли должны быть разными каждый раз.

Благодаря этому основа для счётчика в HOTP алгоритме, в отличие от других алгоритмов, использующих таймер, защищена от рассинхронизации передающих устройств или слишком большого расстояния между ними (такого расстояния, что ответ от получателя приходит позже, чем истечёт время валидности пароля) . Это позволяет HOTP-паролям оставаться действительными в течение неограниченного количества времени, в то время как TOTP -пароли перестанут быть действительными спустя конкретный промежуток времени.

В итоге, при условии использования той же самой хеш-функции, как и в HOTP, данное отличие в работе алгоритма делает TOTP более безопасным и предпочтительным решением для одноразовых паролей

Описание алгоритма

Обозначения

• ${\displaystyle K}$ — Секретный ключ, уникальный для каждого клиента и известный только ему и серверу. Длина — 160 бит (рекомендованная) или 128 бит (минимальная)
• ${\displaystyle C}$ — Текущее состояние 8-байтового счётчика по событию
• ${\displaystyle D}$ — Количество цифр в генерируемом пароле
• ${\displaystyle T}$ — Количество неудачных попыток авторизации, после которых сервер заблокирует соединение с клиентом
• ${\displaystyle s}$ — Параметр рассинхронизации. Определяет максимальное расхождение между счётчиком сервера и клиента, при котором одноразовый пароль будет принят.

Общее описание

Алгоритм должен возвращать не меньше 6 цифр для обеспечения достаточной безопасности пароля. В зависимости от уровня требований к защите, можно использовать значения для HOTP, состоящие из большего количества цифр, для получения более стойкого к атакам пароля. Работу алгоритма можно описать следующей формулой :

$${\displaystyle HOTP(K,C)=Truncate(HMAC-SHA-1(K,C))}$$

1. Создается строка ${\textstyle HS}$ размером в 20 байт, применяя хеш-функцию ${\displaystyle HMAC-SHA-1}$ , инициализированная параметрам ${\displaystyle K}$ и ${\displaystyle C}$ : ${\displaystyle HS=HMAC-SHA-1(K,C)}$
2. Выбираются определённым образом 4 байта из ${\displaystyle HS}$ : ${\displaystyle S_{bits}=Truncate(HS)}$
   1. Четыре последних бита последнего байта результата ${\displaystyle S_{bits}[19]}$ преобразуются в число ${\displaystyle offset\in (0,15)}$
   2. Последовательность байтов ${\displaystyle HS[offset]..HS[offset+3]}$ преобразуется в переменную ${\displaystyle P}$
   3. ${\displaystyle Truncate(HS)}$ возвращает последние 31 бита ${\displaystyle P}$ Причина, из-за которой игнорируется старший бит ${\displaystyle P}$ , заключается в разных вариантах реализации целочисленных вычислений у разных процессоров
3. Результат работы ${\displaystyle Truncate()}$ преобразуется к последовательности из ${\displaystyle D}$ цифр: ${\displaystyle HOTP=toNumber(Truncate(HS))\,\,mod\,10^{D}}$

Пример вычисления 6-значного значения HOTP

Данный пример демонстрирует работу алгоритма, генерирующего шестизначный числовой пароль из кода аутентификации размером в 160 бит. Пусть на определённом шаге было вычислено значение строки ${\displaystyle hmac\_result[0]...hmac\_result[19]}$ из ${\displaystyle HMAC-SHA-1}$

int offset = hmac_result[19] & 0xf;
int bin_code = (hmac_result[offset] & 0x7f) << 24
           | (hmac_result[offset+1] & 0xff) << 16
           | (hmac_result[offset+2] & 0xff) <<  8
           | (hmac_result[offset+3] & 0xff);

Тогда результат будет выглядеть следующим образом:

1. Последний байт имеет значение 0x5a
2. Значение сдвига, полученное из младших 4 бит — 0xa, это даёт нам число 10
3. Значение 4 последовательных байтов, начиная с 10-й позиции — 0x50ef7f19, которое преобразуется в двоичный код DBC1 (dynamic binary code)
4. MSB, полученное из DBC1, равно 0x50. Поэтому DBC2 = DBC1 = 0x50ef7f19
5. Далее, бинарные значения рассматриваются как положительного числа, записанного в порядке от старшего к младшему, у которого первый байт маскируется значением 0x7f.
6. Для того, чтобы получить шестизначное число для HOTP, необходимо взять число, полученное на предыдущем шаге по модулю 10 ⁶ — ${\displaystyle HOTP=DBC2{\pmod {10^{6}}}=872921}$

Проверка одноразового пароля

Проверка значений счётчиков

При создании нового одноразового пароля генератором (клиентом) значение счётчика клиента увеличивается на единицу. В дальнейшем значение счётчика ${\displaystyle C}$ подаётся на вход хеш-функции ${\displaystyle HMAC-SHA-1}$ вместе с ключом ${\displaystyle K}$ . После этого ${\displaystyle C}$ будет отправлено серверу аутентификации, где оно будет сравнено со значением, вычисленным сервером. Если значения совпадают с учётом расхождения не больше параметра рассинхронизации ${\displaystyle s}$ , то сервер увеличивает на единицу значение своего счётчика. Если данные не совпали, то сервер начинает ресинхронизацию и повторяет её в случае неудачи, пока не будет достигнут предел неудачных попыток аутентификации ${\displaystyle T}$ . После этого сервер блокирует учётную запись пользователя .

Рассинхронизация между клиентом и сервером

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

1. Аутентификация не пройдена. Клиент обновил значение счётчика после создания пароля, а значение на сервере не изменилось
2. Проблема связи. Клиент инкрементировал значение счётчика после отправки пароля, но пароль не достиг сервера

Это приводит к необходимости использования параметра рассинхронизации ${\displaystyle s}$ , который будет отвечать за размеры окна, в пределах которого значения счётчика клиента и сервера будут считаться синхронизированными.

Ресинхронизация счётчика

Ресинхронизация проводится исключительно сервером. Она заключается в расчёте нового значения для своего счётчика событий, чтобы его значение совпадало с полученным от клиента в пределах разницы между значениями не более ${\displaystyle s}$ . Если это условие выполняется, то сервер обновляет значение собственного счётчика .

В противном случае сервер рассчитывает заново состояние счётчика. В ходе этого процесса сервер может запросить несколько раз дополнительные значения одноразовых паролей. Это сделано для повышения уровня безопасности, так как сравнения паролей в этом случае выполняются для двух или трёх пар. Если предел попыток будет исчерпан, то сервер заблокирует учётную запись пользователя. Параметр ${\displaystyle s}$ также определяет окно, в пределах которого сервер увеличивает счётчик в процессе ресинхронизации. Это ограничение параметром служит для:

1. Ограничения шанса подбора верного значения пароля
2. Предотвратить зацикливания расчёта значения в рамках одной проверки

Безопасность

Надёжность алгоритма

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

• Атака вида « человек посередине » ( Man-in-the-middle ). Злоумышленник не может подделать пересылаемое сообщение, так как пароль изменяется достаточно часто. Множество методов криптографического анализа становятся при этом малопригодными. В некоторых реализациях счётчик, используемый для создания пароля, меняет значение после каждой пересылки. Если сообщения зашифрованы с использованием достаточно сильного шифра, то HOTP делает подбор пароля почти невозможным.
• Атака повторного воспроизведения . Здесь успех зависит от конфигурации самой системы. В случае, например, когда используется сервер аутентификации для предоставления прав на вход пользователя, у атакующего возникает ряд проблем. Сервер после каждого приёма сообщения увеличивает значение счётчика на единицу. Поэтому элементарная отправка дубликата сообщения не пройдет проверку — сообщение создавалось с помощью одного значения, а проверка производится другим.
• Если ключ состоит из ${\displaystyle D}$ произвольных цифр, то вероятность успеха атаки методом прямого перебора при наличии ${\displaystyle T}$ попыток аутентификации до момента блокировки рассчитывается по формуле ${\displaystyle p=sT/10^{D}}$ . Например, при 5 разрешённых попытках ввода шестизначного пароля и размере допустимого окна ${\displaystyle s=30}$ шанс успеха при атаке составляет 0,015 %.

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

Способы усиления защиты

Данные изменения не являются обязательными или рекомендованными авторами алгоритма расширениями. Однако для повышения уровня безопасности собственной реализации можно применить следующие варианты :

• Увеличение длины значения HOTP .

Извлечение каждого нового символа из результата ${\displaystyle HMAC-SHA-1}$ резко уменьшает шансы успешной атаки. Благодаря этому можно сделать процесс работы с паролями удобнее. Например, увеличить количество попыток ввода или расширить диапазон, в котором сравниваются значения счётчиков сервера и клиента.

• Алфавитно-цифровые значения .

Смысл этой идеи заключается в том, чтобы использовать не только цифры для пароля, но ещё и символы A-Z. Вернее, речь идёт о наборе из 32 символов из алфавитно-цифрового множества. Сразу же становится видно, как вырос уровень безопасности паролей, потому что теперь вероятность успеха полного перебора составляет ${\displaystyle sT/32^{6}}$ для паролей, состоящих из 6 символов.

• Ресинхронизация на базе счётчика .

Если условия позволяют клиенту отправлять не только значение HOTP, но и другие данные, то можно сделать процесс ресинхронизации гораздо удобнее и безопаснее, если вместе со значением HOTP клиент будет отправлять серверу состояние счётчика событий. В этом случае значение клиентского HOTP будет выступать в роли имитовставки для состояния счётчика.

Проверяя таким образом значения счётчика на подлинность и соответствие, можно отказаться от использования параметра рассинхронизации, что позволит также повысить уровень защиты алгоритма, потому что в обновлённой системе вероятность успеха атаки прямым перебором будет составлять всего ${\displaystyle T/10^{6}}$ .

Применение

Объединение , стандартизовав HOTP, не давало никаких указаний по поводу реализации алгоритма. Напротив, свобода разработчиков позволяет находить все новые решения, стремясь удовлетворить потребности заказчика и внести инновационный вклад в технологию OTP.

Распространенную реализацию HOTP на Java можно найти в пакете org.jboss.security.otp, который входит в стандартные библиотеки свободно распространяемого веб-сервера Apache Jboss.

Ещё одна реализация на языке Java представлена непосредственно объединением OATH в пакете org.openauthentication.otp.

Можно также упомянуть реализацию — проект OATH Toolkit, библиотека liboath которого позволяет создавать пароли в режиме HOTP и TOTP.

Большое количество низкоинтеллектуальных устройств специально создано для генерации паролей или передачи данных с помощью HOTP и TOTP (Feitian, SecuTech, SmartDisplayer, Vasco, Yubico, ). Алгоритм также используется в домашних сетях для управления периферией с помощью пульта дистанционного управления или мобильного телефона.

Требования к реализации алгоритма

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

В дополнение

HOTP основан на SHA-1 , которая более не считается достаточно устойчивой к коллизиям. Однако, алгоритм HOTP использует только факт случайности числа, посчитанного на её основе, поэтому наличие коллизий непосредственно не влияет на его работу.

Односторонняя аутентификация подразумевает, что клиент по потребности пытается установить связь. После чего сервер отправляет запрос обратно клиенту и проверяет его ответ на подлинность. Модификация алгоритма OCRA позволяет также и пользователю провести аутентификацию сервера.

См. также

• Time-based One-time Password Algorithm

Примечания

Ссылки

• (англ.)
• (англ.)