Аппаратные ключи против программных кодов: что надежнее

На этом месте заканчиваются рекламные обещания про «двухфакторную защиту» и начинается нормальная инженерия.

Автоматизированная фишинговая атака сегодня не обязана взламывать криптографию. Ей достаточно поставить между пользователем и настоящим сайтом прокси-сервер, скопировать страницу входа и переслать введённые данные дальше. Пользователь вводит логин, пароль и шестизначный код из приложения-аутентификатора. Прокси тут же передаёт их легитимному сервису. Сессия установлена. Защита сработала ровно так, как её спроектировали. Просто проектировали её под менее неприятного противника.

Аппаратные ключи безопасности FIDO2/WebAuthn работают иначе. Они не выдают пользователю секрет, который можно перепечатать в чужое окно. Устройство подписывает запрос, предварительно проверив происхождение сайта. Поддельный домен получает не код, а ничего. Это не магия и не «военный уровень шифрования». Это более удачная архитектура.

TOTP: хороший второй фактор с плохим свойством

Программный аутентификатор обычно работает по протоколу TOTP, описанному в RFC 6238. При подключении сервиса приложение получает общий секрет — shared secret. Затем оно объединяет этот секрет с текущей временной меткой, обрабатывает значение через HMAC-SHA1 и показывает пользователю шестизначный код.

Код обычно обновляется каждые 30 секунд. Для защиты от рассинхронизации сервер может принимать значение из небольшого соседнего временного интервала. Это удобно: не нужен интернет, не нужен оператор связи, не нужна отдельная SIM-карта. Достаточно телефона или другого устройства, на котором установлен аутентификатор.

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

TOTP хорошо закрывает несколько распространённых проблем:

• украденный пароль сам по себе больше не даёт войти в аккаунт;
• базы паролей и повторное использование одной комбинации на разных сайтах перестают быть единственным ключом к учётной записи;
• код можно сгенерировать без подключения к мобильной сети;
• приложение-аутентификатор обычно дешевле и проще внедрить, чем парк физических токенов;
• резервный перенос аутентификатора возможен, если сервис и приложение поддерживают такую процедуру.

Статистика Microsoft показывает, что включение 2FA блокирует более 99% автоматических атак, связанных с подбором паролей и кражей учётных данных. Это сильный результат. Но он не означает, что любой второй фактор одинаково устойчив к фишингу. В отчётах маркетинга такие детали обычно теряются. В реальной атаке — нет.

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

Как именно атакуют TOTP

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

Механика выглядит так:

1. Пользователь открывает ссылку на фишинговый домен, визуально похожий на настоящий сервис.

2. Прокси показывает страницу входа, скопированную с легитимного сайта.

3. Введённые логин и пароль отправляются на настоящий сервис.

4. Сервис запрашивает TOTP-код.

5. Пользователь вводит код в фишинговую форму.

6. Прокси пересылает его на настоящий сайт до истечения временного окна.

7. После успешной аутентификации злоумышленник получает сессионные данные или продолжает работу через активную сессию.

На этом этапе злоумышленнику не нужно знать алгоритм генерации TOTP. Ему не требуется извлекать секрет из телефона. Он просто забирает результат аутентификации в момент, когда тот легитимен.

Это принципиальная разница между кражей секрета и перехватом утверждения. Приложение-аутентификатор может не хранить код в облаке, не отправлять его по SMS и вообще работать в авиарежиме. Атака всё равно остаётся возможной, потому что пользователь сам сообщает код чужой форме.

FIDO2 и WebAuthn: ключ не сообщает секрет сайту

Аппаратный ключ FIDO2 — это отдельное устройство с криптографическим материалом внутри. При регистрации на сервисе ключ создаёт пару ключей: открытый и закрытый. Открытый ключ передаётся сервису и может храниться на его стороне. Закрытый остаётся внутри устройства и не покидает его.

Для цифровой подписи применяются асимметричные алгоритмы, в том числе ECDSA на кривой P-256 с SHA-256. Формулировка звучит сухо, но смысл простой: сервер знает открытый ключ, а доказать владение закрытым может только зарегистрированное устройство.

При входе сайт отправляет ключу криптографический запрос. Устройство проверяет контекст операции и подписывает данные. Браузер при этом учитывает origin — происхождение запроса, включая домен. Если пользователь находится на поддельном адресе, ключ не должен выдать корректный ответ для настоящего сервиса.

Именно здесь FIDO2/WebAuthn ломает классическую фишинговую механику. Поддельный домен может идеально скопировать дизайн, текст кнопок и даже последовательность экранов. Он не может заставить ключ подписать запрос от другого origin.

Домен googIe.com с заглавной латинской буквой I вместо строчной l может обмануть человека. Для механизма проверки происхождения это другой адрес. Ключ не оценивает красоту страницы. Он проверяет, кто именно просит подпись.

Что хранится внутри аппаратного ключа

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

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

У аппаратного токена другой профиль риска:

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

Термин «аппаратный» сам по себе ничего не гарантирует. Дешёвый USB-брелок с логотипом безопасности не становится FIDO2-ключом от одного факта наличия разъёма. Нужна поддержка соответствующего стандарта и корректная реализация на стороне сервиса.

Сравнение FIDO2 и TOTP по реальным сценариям

В споре «аппаратные ключи безопасности против программных аутентификаторов» бессмысленно выбирать победителя по числу функций в приложении. Нужно смотреть, какой тип атаки метод закрывает, а какой оставляет открытым.

Таблица не превращает TOTP в бесполезную игрушку. Для личных аккаунтов, небольших команд и сервисов без поддержки WebAuthn это всё ещё практичный второй фактор. Но если задача — противостоять целевому фишингу, компрометации корпоративной почты или атаке на администраторов, аппаратная аутентификация находится на другом уровне.

Почему аппаратный ключ не является бронёй от всего

Рекламное описание обычно заканчивается на словах «защита от фишинга». Инженерное описание на этом только начинается.

FIDO2 закрывает определённый участок цепочки: проверку владения учётными данными и привязку ответа к домену. Он не устраняет все остальные риски.

Кража активной сессии

Если злоумышленник получил cookie уже установленной сессии, повторное прохождение MFA ему может не потребоваться. Аппаратный ключ не умеет телепатически отзывать украденную сессию. Здесь нужны короткие сроки жизни токенов, привязка сессии к контексту устройства, повторная аутентификация для критических операций и серверная аналитика аномалий.

Компрометация конечного устройства

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

Потеря ключа

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

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

Слабая политика восстановления

Большинство систем безопасности ломается не на основном входе, а на восстановлении доступа. Сервис может требовать FIDO2 для обычной аутентификации, но разрешать сброс через письмо, контрольные вопросы или подтверждение по слабому каналу. Тогда атакующий обходит ключ не взломом, а процедурой recovery.

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

Где TOTP всё ещё рациональнее ключа

Аппаратный токен лучше защищает от фишинга. Это не значит, что его нужно немедленно выдать каждому пользователю с доступом к календарю и внутреннему чату.

Стоимость защиты складывается не только из цены устройства. Есть закупка, инвентаризация, доставка, привязка к учётным записям, резервирование, замена утерянных ключей, поддержка USB-A, USB-C и NFC, а также обучение сотрудников. Если процесс входа не продуман, пользователи начнут искать обходы. А обходы в корпоративной среде обычно выглядят как общий аккаунт, отключённый MFA и пароль на стикере.

TOTP оправдан, когда:

• сервис не поддерживает FIDO2/WebAuthn;
• нужно быстро включить второй фактор для большой группы пользователей;
• у компании нет процедуры управления физическими токенами;
• риск массового автоматизированного подбора выше риска целевого фишинга;
• пользователям нужен автономный вход без SMS и мобильной сети;
• есть нормальная политика резервного хранения секретов и восстановления доступа.

Приложение-аутентификатор заметно предпочтительнее SMS-кода. SMS зависит от мобильного оператора, состояния номера и процедур восстановления SIM-карты. Перехват номера, социальная инженерия против оператора и ошибки в процессе перевыпуска SIM-карты остаются отдельным классом рисков. TOTP не решает все проблемы, но хотя бы убирает оператора связи из цепочки генерации кода.

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

Как внедрять аппаратную аутентификацию без корпоративного цирка

1. Разделить пользователей по уровню риска

Один профиль MFA для всех — удобная административная фантазия. У бухгалтера, разработчика, владельца облачного аккаунта и временного подрядчика разные последствия компрометации.

Минимальная группа для обязательных аппаратных ключей:

• глобальные и локальные администраторы;
• владельцы облачных тенантов и доменов;
• сотрудники с доступом к исходному коду и секретам CI/CD;
• специалисты, управляющие резервными копиями;
• пользователи с доступом к персональным и финансовым данным;
• подрядчики, которым выдали привилегированный доступ.

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

2. Выдать минимум два ключа

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

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

3. Не отключать резервный канал без проверки

FIDO2 повышает безопасность, но не отменяет необходимость восстановления. Резервный метод должен быть ограниченным, контролируемым и не слабее настолько, чтобы обнулить эффект от ключа.

Нормальная процедура восстановления включает:

1. подтверждение личности через независимый канал;

2. фиксацию инцидента и причины сброса;

3. временное ограничение привилегий;

4. регистрацию нового ключа;

5. отзыв потерянного или скомпрометированного устройства;

6. проверку активных сессий и токенов доступа.

Просто отправить новый пароль на корпоративную почту, к которой пользователь уже потерял доступ, — это не recovery-процесс. Это запись для будущего расследования.

4. Проверить сценарии входа до обязательного включения

Поддержка FIDO2 может отличаться между браузерами, мобильными приложениями и версиями операционных систем. Отдельно проверяются:

• вход с USB-A и USB-C;
• NFC на смартфонах;
• работа с несколькими ключами;
• регистрация резервного устройства;
• смена телефона;
• удалённый доступ и виртуальные рабочие места;
• восстановление после блокировки;
• администрирование через мобильное приложение;
• запрет слабых fallback-методов.

Нельзя объявлять проект завершённым после того, как один администратор успешно вошёл в сервис на одном ноутбуке. Это демонстрация, не внедрение.

Что выбрать пользователю и что — компании

Для личной почты, аккаунта разработчика, облачного хранилища и менеджера паролей оптимальная схема обычно выглядит так: основной аппаратный ключ, резервный аппаратный ключ и сохранённые в безопасном месте коды восстановления, если сервис их предоставляет.

TOTP следует включать там, где FIDO2 недоступен, а не отказываться от второго фактора вообще. Защита, которая блокирует 99% автоматических атак, по-прежнему лучше отсутствия защиты. Просто не нужно называть её устойчивой к фишингу.

Для компании выбор зависит от концентрации привилегий. Если компрометация одной учётной записи открывает доступ к инфраструктуре, репозиториям, данным клиентов или резервным копиям, программный код уже выглядит компромиссом. Иногда оправданным. Но компромиссом.

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

Итог сравнения прямолинеен. TOTP — доступный и полезный слой защиты от повторного использования паролей и массового автоматизированного взлома. FIDO2/WebAuthn — более сильный механизм против фишинга в реальном времени, потому что закрытый ключ не вводится пользователем, а криптографический ответ привязан к домену.

Практическая политика выглядит так:

• для критических и административных аккаунтов — FIDO2 с двумя зарегистрированными ключами;
• для сервисов без WebAuthn — TOTP вместо SMS;
• для всех методов — контроль восстановления и активных сессий;
• для организаций — реестр ключей, отзыв потерянных устройств и тестирование fallback;
• для пользователей — никакого ввода TOTP-кодов на страницах, открытых по случайным ссылкам;
• для разработчиков сервисов — не объявлять MFA защищённой от фишинга, если она всё ещё просит перепечатать секрет в браузере.

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