Уже более 20 лет в корпоративной среде применяются токены (аутентификаторы) для одноразовых паролей по стандартам отраслевого консорциума OATH (Initiative for Open Authentication). В алгоритме HOTP (HMAC-based One-Time Password) секретный ключ (вектор инициализации) и текущее значение счетчика сгенерированных одноразовых паролей подаются в качестве входных данных в одностороннюю криптографическую хешфункцию (например, SHA-256). Фрагмент вычисленного значения хеш-функции берется в качестве OTP. После каждой отправки одноразового кода генератор паролей и сервер синхронизируют свои счетчики. Алгоритм одноразового пароля на основе времени TOTP (Time-based One-Time Password) использует для вычисления OTP значение текущего времени. Вектор инициализации и счетчик времени (количество 30-секундных интервалов между текущим и начальным временем) подаются на вход криптографической хеш-функции, которая вычисляет OTP. Поскольку криптографические хеш-функции являются односторонними, практического способа вывести секретный ключ из значения хеш-функции не существует.

Аутентификация по одноразовым паролям на основе алгоритмов HOTP/TOTP работает так:

1. Пользователь обращается к целевому ресурсу (устройству или приложению),

2. Пользователь вводит свой идентификатор (логин) в окно (форму) входа,

3. Пользователь получает (с устройства, которым он владеет) и вводит одноразовый пароль (с ПИН-кодом, если тот назначен токену) в окно (форму) входа,

4. Целевой ресурс отправляет на сервер аутентификации введенные пользователем данные,

5. Сервер аутентификации проверяет в своей базе данных, верны ли они,

6. Если проверка будет успешной, пользователь войдет в систему.

Другой подход к получению второго фактора аутентификации используется в режиме «запрос-ответ» (Challenge-Response), где одноразовый пароль (или сгенерированный сервером код) отправляется на зарегистрированный номер (адрес) пользователя в SMS, голосом по телефону, входящим звонком с определенного номера, по электронной почте, в мессенджеры или социальные сети. Эти зарегистрированные в базе сервера аутентификации номера (адреса) тоже рассматриваются как токены.

Аутентификация в режиме «запрос-ответ» работает так:

1. Пользователь обращается к целевому ресурсу (устройству или приложению),

2. Пользователь вводит в окно (форму) входа свой идентификатор (логин),

3. Целевой ресурс отправляет на сервер аутентификации введенные пользователем данные,

4. Сервер аутентификации находит в своей базе токен и генерирует одноразовый пароль для него,

5. Сервер аутентификации отправляет этот пароль на номер (адрес), которым владеет пользователь,

6. Пользователь вводит полученный одноразовый пароль (с ПИН-кодом, если тот назначен токену) в окно (форму) входа целевого ресурса,

7. Целевой ресурс отправляет на сервер аутентификации введенные пользователем данные,

8. Сервер аутентификации проверяет в своей базе данных, верны ли они,

9. Если проверка будет успешной, пользователь войдет в систему

Пуш-уведомления, хотя и не являются, строго говоря, одноразовыми паролями, наследуют у последних многие принципы и технологии.

Аутентификация по пуш-уведомлениям работает так:

1. Пользователь обращается к целевому ресурсу (устройству или приложению) и видит окно (форму) входа,

2. Пользователь вводит свой идентификатор (логин),

3. Целевой ресурс отправляет на сервер аутентификации введенные пользователем данные,

4. Сервер аутентификации находит в своей базе токен,

5. Сервер аутентификации отправляет пользователю пуш-уведомление,

6. Пользователь должен утвердить или отклонить запрос, подтвердив свое решение вводом ПИН-кода или предоставлением биометрии на своем устройстве (если этому пуш-токену назначен ПИН-код),

7. Приложение отправляет в базу данных сервера аутентификации выбор пользователя,

8. Сервер аутентификации проверяет в своей базе данных решение пользователя,

9. Если вход подтвержден, то пользователь войдет в систему.

Системы на базе аппаратных токенов всегда считались довольно сложными и дорогими, поэтому их внедряли, как правило, только крупные организации. С распространением мобильной связи стала использоваться передача одноразовых паролей в SMS. Хотя такой подход позволяет удешевить внедрение OTP, сейчас он считается ненадежным (SMS могут теряться и приходить с большой задержкой) и небезопасным (уязвим к перехвату SMS и перевыпуску SIM-карты. То же самое относится, в общем, и к отправке OTP по электронной почте.

Поэтому сейчас стали широко использоваться программные аутентификаторы – приложения для настольных и мобильных операционных систем, а также боты для Telegram и других мессенджеров. Такие приложения позволяют вычислять одноразовые пароли из полученного с сервера и введенного в них кода (вектора) инициализации. Этот код передается в приложение либо в виде строки символов, либо в QR-коде. Кроме того, программные токены могут получать пуш-уведомления, которые сервер аутентификации автоматически отправляет при попытке входа пользователя в систему. Режим пуш обеспечивает наилучшее сочетание удобства и защиты, так как используется привычное пользователю устройство, доступ к которому можно защитить ПИН-кодом или биометрией. Недостатки – относительная сложность в реализации и зависимость от сторонних облачных сервисов. Secure Authentication Server поддерживает следующие типы аутентификаторов (токенов):

♦ Аппаратные аутентификаторы, соответствующие RFC 4226 (HOTP) и RFC 6238 (TOTP):

√ SafeNet eToken PASS;

√ SafeNet eToken 3400;

√ Рутокен OTP.

♦ Мобильное приложение MFASOFT для платформ Android и iOS, соответствующее RFC 4226 (HOTP) и RFC 6238 (TOTP), с автоматической активацией, безопасной передачей вектора инициализации и поддержкой пуш-уведомлений;

♦ Google-совместимые программные аутентификаторы для платформ Android и iOS с синхронизацией по событию и по времени:

√ Google Authenticator;

√ Microsoft OTP;

√ Yandex ключ;

√ Bitrix OTP.