Как TOTP получает код

RFC 6238 задает TOTP как вариант HOTP, в котором счетчик заменен временным фактором. В упрощенном виде алгоритм получает число шагов между начальным временем T0 и текущим Unix-временем, затем передает это значение в HOTP с общим секретным ключом. RFC называет 30 секунд значением временного шага по умолчанию. Проверьте часы.

Устройство пользователя и проверяющий сервис должны знать один и тот же секрет, T0 и длину временного шага. Если часы устройства сильно расходятся с сервером, код может не пройти проверку. Сервер обычно сравнивает код с текущим временным окном и может учесть небольшой сдвиг передачи. RFC рекомендует ограничивать окно проверки. Чем оно шире, тем больше риск.

Почему «одноразовый» не значит «невозможно повторить»

Код остается тем же внутри одного временного шага. Само вычисление TOTP не доказывает, что значение уже не использовали: запрет повтора и учет попыток зависят от логики сервиса. Поэтому код из перехваченного сообщения потенциально можно повторно предъявить в допустимом окне, если приложение не контролирует повтор.

Секрет для каждого устройства или пользователя должен быть отдельным и храниться защищенно. Если он утек, новые коды можно рассчитывать без исходного устройства. В отличие от пароля, TOTP не требует вводить один постоянный секрет при каждом входе, но настройка и восстановление зависят от сервиса.

Чего TOTP не решает

Короткий интервал жизни кода сам по себе не защищает от фишинговой страницы, которая передаст код злоумышленнику в реальном времени. TOTP также не шифрует соединение и не заменяет контроль сессий. Сервис должен проверять код на сервере, ограничивать попытки и иметь отдельный процесс восстановления доступа.

Связанные материалы: двухфакторная аутентификация, SSH и резервное копирование. Использованы RFC 6238 и RFC 4226, проверенные 8 октября 2026 года; коды и учетные записи не создавались и не проверялись.