Эволюция одноразовых кодов: от TAN к Passkeys

TL;DR

Одноразовые коды (OTP) — основа повседневной цифровой безопасности. Мы вводим их при входе в банк, при подтверждении перевода, при доступе к облаку. Но не все коды одинаково безопасны.

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

TAN или Как всё начиналось

Если вы когда-нибудь пользовались интернет-банком в начале 2000-х, скорее всего, вы видели TAN-листы — бумажные или присылаемые по SMS коды, каждый из которых использовался один раз для подтверждения транзакции.

TAN (Transaction Authentication Number) — список одноразовых чисел, который выдавался банком клиенту. Один код — одна операция.

• Пример: 2341, 9884, 1376

• Способ доставки: бумага или SMS

Почему устарело:

• Коды короткие, обычно 4 цифры

• Нет привязки ко времени или контексту транзакции

• Уязвимо к MITM, подмене форм и утечкам

HOTP и TOTP спешат на помощь

Со временем на смену статичным спискам пришли алгоритмы, генерирующие коды на лету.

HOTP (HMAC-Based One-Time Password)

Алгоритм описан в RFC 4226. Он использует счётчик и секретный ключ:

HOTP = HMAC(secret, counter)

Этот подход применялся в аппаратных токенах вроде RSA SecurID.

TOTP (Time-Based One-Time Password)

Дальнейшее развитие идеи — алгоритм из RFC 6238. Вместо счётчика — текущее время, округлённое до 30 секунд:

T = floor((time - t0) / 30) TOTP = HMAC(secret, T)

Коды обычно шестизначные, живут 30 секунд.

Плюсы:

• Работает офлайн

• Криптостойкость (HMAC-SHA1/256)

• Простота реализации

Минусы:

• Требует ручного ввода

• Потеря устройства = потеря доступа

Push и App-TAN: проще и человечнее

Чтобы упростить UX, появились пуш-уведомления. Вместо ввода кода вы просто подтверждаете вход:

«Вы пытаетесь войти в GitHub с устройства Chrome на Ubuntu?»
[Да] [Нет]

Это решение применяют Google Prompt, Microsoft Authenticator, банковские Push-TAN). Что получаем:

• Привязку к устройству

• Контекст операции (локация, браузер)

• Возможность отзыва

И UX лучше, и защита от фишинга уже куда серьезнее.

Аппаратная безопасность: U2F и FIDO2

Следующий шаг — аппаратные токены вроде YubiKey, SoloKey или Google Titan. Как это работает:

• Устройство хранит приватный ключ

• Подписывает challenge от сервера

• Ключ нельзя извлечь или клонировать

Итог — максимальная защита к фишингу и MITM, нет секретов в браузере или на сервере, но нужно физическое устройство. Хотя по факту — носится как брелок или вшито в ноутбук.

Новый стандарт: Passkeys

Passkeys — это не просто замена паролям. Это замена всей модели аутентификации:

• Работают через WebAuthn и FIDO2

• Хранятся на устройстве: в Android, iOS, macOS, Windows

• Проверка через биометрию или PIN

• Нет кода, нет пароля, нет ручного ввода

Уровень защиты:

• Криптография уровня FIDO2

• Удобство на уровне “просто глянул в камеру”

Подробнее — webauthn.io

Сравнение поколений

Что всё это значит

Путь от TAN к Passkeys — это не просто эволюция алгоритмов. Это движение к модели, в которой безопасность уходит в инфраструктуру, а пользователь всё меньше должен помнить, вводить и проверять.

Если вы проектируете систему авторизации:

• избегайте TAN/SMS;

• начинайте хотя бы с TOTP;

• стремитесь к push или аппаратным ключам;

• если нужен идеальный UX — выбирайте Passkeys.

---

Готов обсудить дополнения, опечатки, и альтернативные модели — особенно если вы работаете с аутентификацией на backend или проектируете user journey.

Этот текст подготовлен совместно с AI, с бережной верификацией фактов, терминов и структуры. Все выводы и обобщения — результат анализа. Если заметите неточности — приветствую в комментариях для уточнений.