HOTP

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

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

$${\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}$, заключается в разных вариантах реализации целочисленных вычислений у разных процессоров[1]
3. Результат работы ${\displaystyle Truncate()}$ преобразуется к последовательности из ${\displaystyle D}$ цифр: ${\displaystyle HOTP=toNumber(Truncate(HS))\,\,mod\,10^{D}}$

Данный пример[1] демонстрирует работу алгоритма, генерирующего шестизначный числовой пароль из кода аутентификации размером в 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[7] (dynamic binary code)
4. MSB, полученное из DBC1, равно 0x50. Поэтому DBC2[8]= 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].

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

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

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

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

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

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

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

• Атака вида «человек посередине» (Man-in-the-middle). Злоумышленник не может подделать пересылаемое сообщение, так как пароль изменяется достаточно часто. Множество методов криптографического анализа становятся при этом малопригодными. В некоторых реализациях счётчик, используемый для создания пароля, меняет значение после каждой пересылки. Если сообщения зашифрованы с использованием достаточно сильного шифра, то HOTP делает подбор пароля почти невозможным.[3]

• Атака повторного воспроизведения. Здесь успех зависит от конфигурации самой системы. В случае, например, когда используется сервер аутентификации для предоставления прав на вход пользователя, у атакующего возникает ряд проблем. Сервер после каждого приёма сообщения увеличивает значение счётчика на единицу. Поэтому элементарная отправка дубликата сообщения не пройдет проверку — сообщение создавалось с помощью одного значения, а проверка производится другим.[3]

• Если ключ состоит из ${\displaystyle D}$ произвольных цифр, то вероятность успеха атаки методом прямого перебора при наличии ${\displaystyle T}$ попыток аутентификации до момента блокировки рассчитывается по формуле ${\displaystyle p=sT/10^{D}}$. Например, при 5 разрешённых попытках ввода шестизначного пароля и размере допустимого окна ${\displaystyle s=30}$ шанс успеха при атаке составляет 0,015 %.

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

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

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

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

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

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

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

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

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

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