Стойкость 2FA к фишингу: 5 факторов надежности защиты

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

С точки зрения атакующего классическая 2FA часто выглядит не как крепость, а как дверь с дополнительной ручкой. Пользователь вводит логин, пароль и одноразовый код в прокси-сессию. Прокси передаёт данные настоящему сервису, получает сессионную cookie и отдаёт её оператору атаки. Пароль после этого можно сменить. Активную сессию — не всегда.

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

Иллюзия безопасности: почему SMS, TOTP и Push проигрывают фишингу

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

Это принципиальный дефект, а не мелкая недоработка интерфейса.

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

Сценарий обратного фишинга выглядит так:

1. Пользователь открывает ссылку из письма, сообщения или рекламного объявления.

2. Попадает на страницу, визуально похожую на форму входа Microsoft 365, Google Workspace, VPN-шлюза или корпоративного портала.

3. Вводит логин и пароль.

4. Фишинговый сервер пересылает эти данные на настоящий сервис.

5. Настоящий сервис запрашивает второй фактор.

6. Пользователь вводит SMS-код, TOTP либо подтверждает push-запрос.

7. Прокси получает ответ сервиса и может перехватить токен авторизации или сессионную cookie.

Здесь нет необходимости взламывать криптографию. Нет необходимости подбирать код. Нет необходимости внедрять малварь в смартфон. Атака использует нормальную работу системы против самой системы.

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

SMS: второй фактор, который живёт в телеком-инфраструктуре

SMS остаётся популярным по одной причине: он доступен почти всем и не требует отдельного оборудования. К безопасности это имеет слабое отношение.

У SMS есть несколько независимых проблем:

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

Даже если исключить SIM swapping, остаётся обратный фишинг. Код не знает, на каком домене его ввели. Он не знает, кто именно запросил подтверждение. Он просто подтверждает действие в течение ограниченного времени.

SMS-код нельзя считать надёжным решением для защиты токенов авторизации от фишинга. Он может быть лучше полного отсутствия второго фактора, но это сравнение с нулём. В корпоративной системе с доступом к почте, CRM, платёжным данным или административной панели такой уровень давно недостаточен.

TOTP: код меняется, атака — нет

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

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

У TOTP нет встроенной привязки к домену. Приложение не проверяет, что код запрашивает именно example.com, а не домен-двойник с похожим именем. Браузер также не может доказать, что введённый код предназначался конкретному Origin.

Поэтому TOTP не является устойчивым к фишингу методом, даже если код действует всего несколько десятков секунд. Короткое время жизни усложняет повторное использование, но не останавливает оператора атаки в реальном времени. MITM-прокси как раз и построен на скорости.

Push: удобство, которое превратили в оружие

Push-аутентификация убирает ручной ввод кода. Пользователь получает уведомление и нажимает кнопку подтверждения. Казалось бы, проблема решена. Нет.

Злоумышленник может инициировать настоящую авторизацию украденным паролем и отправить жертве серию запросов. Пользователь видит привычные уведомления, раздражается, торопится и подтверждает одно из них. Такой сценарий называют MFA bombing или push fatigue — атакой через утомление запросами.

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

Многофакторность здесь есть. Фишингоустойчивости — нет.

Механика MITM: где именно ломается традиционная 2FA

MITM-атака в контексте аутентификации не обязательно означает перехват сетевого трафика между браузером и сервером. HTTPS по-прежнему может работать корректно. Сертификат настоящего сайта может быть действительным. Шифрование канала может не нарушаться вообще.

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

Схема работает за счёт трёх особенностей классической 2FA:

1. Секрет вводится человеком.

Пароль, SMS-код и TOTP можно перенести в другую форму. Система не отличает легитимный ввод от ввода через прокси.

2. Код не связан с доменом.

Один и тот же TOTP-код не содержит информации о том, для какого Origin он предназначен. SMS тем более не знает ничего о браузере.

3. Сессия может быть передана атакующему.

После успешной аутентификации сервис выдаёт cookie, bearer-токен или другой артефакт сессии. Если прокси получил его, пароль и второй фактор уже выполнили свою работу — для атакующего.

Фишинг в этой модели не крадёт только пароль. Он крадёт результат доверенной авторизации.

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

Пять факторов, по которым нужно оценивать 2FA

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

Пять ключевых факторов выглядят так:

1. Domain binding — привязка к домену.

Аутентификатор должен понимать, для какого сервиса он создаёт доказательство.

2. Channel binding — привязка к каналу.

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

3. Асимметричная криптография.

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

4. Автоматическая подпись challenge.

Пользователь не должен копировать секрет из приложения в браузер. Устройство получает challenge и подписывает его в контексте разрешённого домена.

5. Защита ключевого материала.

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

FIDO2, WebAuthn и CTAP: что меняется в криптографической модели

FIDO2 не является одним отдельным приложением. Это набор протоколов и механизмов, в котором WebAuthn отвечает за взаимодействие браузера с веб-сервисом, а CTAP — за связь внешнего аутентификатора с платформой пользователя.

При регистрации пользователь создаёт пару ключей:

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

Во время входа сервис отправляет challenge. Браузер передаёт его аутентификатору вместе с контекстом сайта. Аутентификатор проверяет домен и подписывает challenge закрытым ключом. Сервер проверяет подпись открытым ключом.

Важен не сам факт использования ключевой пары. Важен контекст, в котором создаётся подпись.

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

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

Почему прокси не может просто переслать WebAuthn-запрос

Обычный reverse proxy способен передавать запросы между браузером и настоящим сервисом. Но в WebAuthn подпись формируется не только на основании случайного challenge. В операцию входит информация о проверяющем и происхождении запроса.

Устройство видит, что пользователь взаимодействует с конкретным Origin. Поддельный домен не получает права использовать учётные данные настоящего домена. Даже если прокси передаст challenge на сервер, итоговая подпись будет связана с другим контекстом либо операция не будет выполнена.

Это не делает FIDO2 магическим щитом. Возможны компрометация конечной точки, кража активной сессии после входа, вредоносные расширения браузера, атаки на восстановление учётной записи и ошибки интеграции. Но классический reverse-proxy phishing, который успешно крадёт SMS и TOTP в реальном времени, упирается в криптографическую границу.

Привязка к домену: главный барьер для злоумышленника

В традиционной 2FA пользователь является переносчиком секрета. Он видит код в одном месте и вводит его в другом. В FIDO2 пользователь не переносит секрет. Устройство само проверяет, кому разрешено подписывать запрос.

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

Доменная привязка решает сразу несколько задач:

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

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

Passkeys против аппаратных ключей

Аппаратный FIDO2-токен и passkey решают одну задачу разными способами.

Аппаратный токен — физическое устройство, которое пользователь подключает через USB, NFC или Bluetooth. Закрытый ключ находится внутри токена. Для критичных административных ролей это даёт понятную модель контроля: ключ нельзя просто экспортировать в файл и отправить в облако.

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

Упрощённое сравнение:

Нельзя сводить вопрос к спору «токены лучше passkeys» или наоборот. Уязвимость появляется не только в механизме входа, но и в процедуре восстановления. Если потерянный passkey можно заменить по ссылке, отправленной на резервную почту без дополнительной проверки, атакующий обойдёт сильный фактор через слабый recovery-flow.

AAL3, Zero Trust и корпоративная политика без самообмана

NIST SP 800-63-4 разделяет уровни доверия к аутентификаторам. На уровне AAL3 требования к защите существенно выше, чем простая комбинация пароля и одноразового кода. Для организаций это означает переход от формального наличия MFA к оценке того, устойчив ли конкретный фактор к фишингу и перехвату.

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

Для корпоративной инфраструктуры это переводится в несколько практических решений:

• доступ к административным панелям разрешается только через FIDO2 или passkeys;
• SMS и TOTP остаются временным переходным механизмом, а не целевой политикой;
• push-подтверждения ограничиваются number matching, геоконтекстом и скоростными лимитами;
• резервные способы входа не должны быть слабее основного фактора;
• привилегированные роли получают отдельные политики и физические токены;
• сессии имеют ограниченное время жизни и повторную проверку при опасных действиях;
• события регистрации нового устройства и восстановления доступа попадают в SIEM;
• повторное использование украденных cookie отслеживается отдельными правилами, а не только средствами MFA.

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

Ошибки внедрения, которые обнуляют сильный фактор

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

1. Оставляют TOTP как постоянный обходной путь.

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

2. Не ограничивают регистрацию новых аутентификаторов.

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

3. Слишком доверяют восстановлению доступа.

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

4. Не разделяют пользовательские и привилегированные роли.

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

5. Не отзывают ключи при увольнении и смене роли.

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

6. Разрешают старые протоколы входа.

Legacy authentication, IMAP, POP3, устаревшие VPN-клиенты и локальные интеграции могут обходить современную MFA. В панели всё зелёное. В логах — незаметный пролом через старый интерфейс.

7. Не проверяют Origin и параметры WebAuthn на стороне приложения.

Веб-интеграция должна корректно обрабатывать RP ID, Origin, challenge, счётчик использования и статусы аутентификатора. Ошибка в реализации способна превратить хороший стандарт в дорогой декоративный элемент.

Что делать с SMS, TOTP и Push на практике

Полностью выключить классическую 2FA за один день удаётся не каждой компании. У части пользователей старые телефоны, у части — внешние подрядчики, у части — приложения, которые ещё не поддерживают passkeys. Но переход можно выстроить без самообмана.

Сначала нужно разделить методы по уровню защиты, а не складывать их в одну категорию MFA:

Далее политика должна двигаться в сторону запрета слабого метода там, где уже доступен сильный. Не «рекомендуем passkeys», а «для этой роли вход по SMS запрещён». Иначе пользователь выберет привычный путь, а атакующий — самый дешёвый.

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

1. Инвентаризировать методы и зависимости.

Соберите данные о том, кто использует SMS, TOTP, push, аппаратные ключи и резервные коды. Отдельно отметьте административные учётные записи, сервисные интеграции и старые протоколы.

2. Разделить доступ по критичности.

Почта, VPN, системы управления идентификацией, облачные консоли и панели биллинга должны получить приоритет. Критичная инфраструктура не должна ждать, пока passkeys появятся во всех внутренних приложениях.

3. Ввести FIDO2 для привилегированных ролей.

Минимум два зарегистрированных токена на администратора — основной и резервный. Резервный не должен храниться в ящике стола вместе с наклейкой, где написан PIN.

4. Перевести массовых пользователей на passkeys.

Упростите регистрацию, настройте понятное восстановление и заранее подготовьте сценарии потери устройства. Хорошая криптография не переживёт плохой onboarding, если сотрудники начнут обходить систему через поддержку.

5. Закрыть слабые recovery-пути.

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

6. Ограничить срок и область действия сессий.

MFA не должна выдавать бессрочный билет в корпоративное облако. Для административных операций нужны step-up-проверки и повторная криптографическая аутентификация.

7. Проверить интеграции и старые клиенты.

Ищите места, где токены выдаются через отдельный API, прокси, мобильный клиент или устаревший протокол. Основной веб-портал может быть защищён идеально, пока внутренний коннектор принимает пароль без MFA.

8. Тестировать не только вход, но и атаку.

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

Итог: надёжнее не «самая сильная 2FA», а правильная криптографическая граница

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

SMS, TOTP и Push остаются многофакторными методами. Но они не дают устойчивости к фишингу. Их можно перехватить через reverse proxy, выманить социальной инженерией или обойти через восстановление доступа. Разница между ними — в удобстве и наборе дополнительных рисков, а не в наличии криптографической защиты от MITM.

FIDO2, WebAuthn, CTAP, passkeys и смарт-карты работают на другом уровне. Они используют асимметричную криптографию, привязку к домену и автоматическую обработку challenge. Фишинговый сайт может выглядеть убедительно, но не становится легитимным Origin от одного логотипа.

Для бизнеса вывод жёсткий. MFA без проверки фишингоустойчивости — неполная политика безопасности. Passkey без защиты восстановления — половинчатая архитектура. FIDO2 при открытом legacy-протоколе — дорогая ширма.

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