HOTP

• ${\displaystyle }$ — Секретний ключ, унікальний для кожного клієнта і відомий тільки йому і серверу. Довжина — 160 біт (рекомендована) або 128 біт (мінімальна)
• ${\displaystyle }$ — Поточний стан 8-байтового лічильника події
• ${\displaystyle }$ — Кількість цифр в генерованому паролі
• ${\displaystyle }$ — Кількість невдалих спроб авторизації, після яких сервер заблокує з'єднання з клієнтом
• ${\displaystyle }$ — Параметр розсинхронізації. Визначає максимальну розбіжність між лічильником сервера і клієнта, при якому одноразовий пароль буде прийнятий.

Алгоритм повинен повертати не менше 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 HTOP=toNumber(Truncate(HS))\,\,mod\,10^{D}}$

Даний приклад демонструє роботу алгоритму, генеруючого шестизначний цифровий пароль з коду аутентифікації розміром в 160 біт. Нехай на певному кроці було обчислено значення рядка ${\displaystyle }$ з ${\displaystyle }$

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 }$

При створенні нового одноразового пароля генератором (клієнтом) значення лічильника клієнта збільшується на одиницю. Надалі значення лічильника ${\displaystyle }$ подається на вхід хеш-функції ${\displaystyle }$ разом з ключем ${\displaystyle }$. Після цього ${\displaystyle }$ буде відправлено сервера аутентифікації, де воно буде порівняно зі значенням, обчисленим сервером. Якщо значення збігаються з урахуванням розбіжності не більше параметра розсинхронізації ${\displaystyle }$, то сервер збільшує на одиницю значення свого лічильника. Якщо дані не співпали, то сервер починає ресинхронизацию і повторює її в разі невдачі, поки не буде досягнута межа невдалих спроб аутентифікації ${\displaystyle }$. Після цього сервер блокує обліковий запис користувача.

Як було згадано раніше, клієнт оновлює значення лічильника подій при кожній генерації одноразового пароля. У свою чергу, значення лічильника на сервері збільшується тільки після успішної автентифікації. Виходячи з цих тверджень можна описати причини, чому впровадження процесу ресинхронізації необхідно:

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

Це призводить до необхідності використання параметра розсинхронізації ${\displaystyle }$, який буде відповідати за розміри вікна, в межах якого значення лічильника клієнта і сервера будуть вважатися синхронізованими.

Ресинхронізація проводиться виключно сервером. Вона полягає в розрахунку нового значення для свого лічильника подій, щоб його значення співпадало з отриманими від клієнта в межах різниці між значеннями не більше ${\displaystyle }$. Якщо ця умова виконується, то сервер оновлює значення власного лічильника.

В іншому випадку сервер розраховує заново стан лічильника. В ході цього процесу сервер може запросити кілька разів додаткові значення одноразових паролів. Це зроблено для підвищення рівня безпеки, так як порівняння паролів у цьому випадку виконуються для двох або трьох пар. Якщо кількість спроб буде вичерпано, то сервер блокує обліковий запис користувача. Параметр ${\displaystyle }$ також визначає вікно, в межах якого сервер збільшує лічильник в процесі ресинхронізації. Це обмеження параметром служить для:

1. Обмеження шансу підбору вірного значення пароля
2. Запобігти зацикленню розрахунку значення в рамках однієї перевірки

Системи захисту, побудовані з використанням HOTP, володіють високим ступенем надійності. Вони, в більшості своїй, стійкі до широко поширеним криптографічних атак, наприклад:

• Атака виду «людина посередині» (Man-in-the-middle). Зловмисник не може підробити пересланого запрошення повідомлення, так як пароль змінюється досить часто. Безліч методів криптографічного аналізу стають при цьому малопридатними. У деяких реалізаціях лічильник, який використовується для створення пароля, змінює значення після кожної пересилання. Якщо повідомлення зашифровані з використанням досить сильного шифру, то HOTP робить підбір пароля майже неможливим.

• Атака повторного відтворення. Тут успіх залежить від конфігурації самої системи. У випадку, наприклад, коли використовується сервер аутентифікації для надання прав на вхід користувача, у атакуючого виникає ряд проблем. Сервер після кожного прийому повідомлення збільшує значення лічильника на одиницю. Тому елементарна відправка дубліката повідомлення не пройде перевірку — повідомлення створювалося за допомогою одного значення, а перевірка проводиться іншим.

• Якщо ключ складається з ${\displaystyle }$ довільних цифр, то ймовірність успіху атаки методом прямого перебору при наявності ${\displaystyle }$ спроб аутентифікації до моменту блокування розраховується за формулою ${\displaystyle }$. Наприклад, при 5 дозволених спробах введення шестизначного пароля і розмірі допустимого вікна ${\displaystyle }$ шанс успіху при атаці становить 0,015 %.

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

Дані зміни не є обов'язковими або рекомендованими авторами алгоритму розширеннями. Однак для підвищення рівня безпеки власної реалізації можна застосувати такі варіанти:

• Збільшення довжини значення HOTP.

Витяг кожного нового символу з результату ${\displaystyle }$ різко зменшує шанси успішної атаки. Завдяки цьому можна зробити процес роботи з паролями зручніше. Наприклад, збільшити кількість спроб введення або розширити діапазон, в якому порівнюються значення лічильників сервера і клієнта.

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

Сенс цієї ідеї полягає в тому, щоб використовувати не тільки цифри для пароля, але ще і символи A-Z. Вірніше, мова йде про набір з 32 символів з алфавітно-цифрового множини. Відразу ж стає видно, як виріс рівень безпеки паролів, тому що тепер ймовірність успіху повного перебору складає ${\displaystyle }$ для паролів, які складаються з 6 символів.

• Ресинхронізація на базі лічильника.

Якщо умови дозволяють клієнту відправляти не тільки значення HOTP, але і інші дані, то можна зробити процес ресинхронізації набагато зручніше і безпечніше, якщо разом зі значенням HOTP клієнт буде відправляти серверу стан лічильника подій. В цьому випадку значення клієнтського HOTP буде виступати в ролі імітовставки для стану лічильника.

Перевіряючи таким чином значення лічильника на достовірність і відповідність, можна відмовитися від використання параметра розсинхронізації, що дозволить також підвищити рівень захисту алгоритму, тому що в оновленій системі ймовірність успіху атаки прямим перебором буде становити всього ${\displaystyle }$.

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