Phishing‑Resistant MFA: защита от фишинга при аутентификации
Автор: Петухов Олег Анатольевич, эксперт по информационной безопасности, руководитель юридической компании ЛЕГАС
Сайт: legascom.ru
Email: petukhov@legascom.ru
Многофакторная аутентификация (MFA) давно стала стандартом ИБ, но статистика показывает: атаки на учётные записи остаются одним из самых частых векторов компрометации. Причина - не в отсутствии MFA, а в эволюции самих атак: современный фишинг научился обходить традиционные механизмы второго фактора. Разберём, почему привычные методы перестают работать и какие подходы реально защищают от фишинговых сценариев.
Почему традиционная MFA не спасает от современного фишинга
Раньше второй фактор был рассчитан на защиту от кражи пароля: он подтверждал, что пользователь владеет устройством или каналом связи. Но архитектура многих решений допускает воспроизведение фактора вне контекста конкретного сервиса. Коды из СМС, одноразовые пароли из приложений и пуш‑подтверждения можно ввести на любом сайте - система примет их, если они введены в допустимое время.
Этим и пользуются злоумышленники в атаках типа Adversary‑in‑the‑Middle (AiTM). Фишинговый сайт выступает посредником между пользователем и реальным сервисом: он проксирует весь процесс аутентификации. Пользователь вводит логин, пароль и подтверждает вход вторым фактором, думая, что работает с легитимным ресурсом. В результате атакующий получает не только учётные данные, но и активную сессию.
Таким образом, классическая MFA защищает от перебора паролей и утечек данных, но не от сценариев, где злоумышленник в реальном времени передаёт легитимные запросы сервису.
Что такое Phishing‑Resistant MFA и как это работает
Phishing‑Resistant MFA - это принципиально иной подход: подтверждение входа привязывается к конкретному домену и устройству. Механизм строится на криптографической подписи запроса: устройство пользователя проверяет адрес ресурса и формирует подпись только для легитимного домена. На поддельном сайте подпись не создаётся, и атакующий не может воспроизвести процедуру аутентификации.
На практике такие решения реализуются на базе стандартов FIDO2 и WebAuthn. В их основе - пара криптографических ключей:
Закрытый ключ хранится на устройстве пользователя (например, в TPM, Secure Enclave или на аппаратном токене) и никогда не передаётся в сеть.
Открытый ключ регистрируется на стороне сервиса и используется для проверки подписи.
При входе сервис формирует криптографический вызов, устройство подписывает его закрытым ключом, система проверяет подпись и подтверждает аутентификацию. Даже если пользователь попал на фишинговый сайт, злоумышленник не получит пригодный для использования фактор.
Альтернативный способ защиты: разделение каналов
Помимо криптографии, снизить риски AiTM‑атак помогает разделение каналов передачи аутентификационных данных: логин и пароль вводятся в одном канале (например, в браузере), а второй фактор подтверждается в другом (через отдельное мобильное приложение). Ключевое условие - запрос на второй фактор должен инициироваться доверенной системой через защищённый API. Это мешает злоумышленнику самостоятельно запускать поток подтверждения.
Типичные уязвимости, которые сводят на нет защиту
Даже при внедрении современных механизмов устойчивость к фишингу может быть нарушена из‑за унаследованных компонентов инфраструктуры («легаси»). Наиболее распространённые проблемы:
резервные методы входа через СМС или одноразовые коды;
устаревшие протоколы доступа;
сервисные учётные записи без строгой аутентификации;
долгоживущие сессии, пригодные для использования после компрометации;
разрозненная система управления доступом.
Формальное наличие MFA не гарантирует безопасность, если остаются альтернативные пути входа, которыми могут воспользоваться атакующие.
Пример реализации: архитектура на базе MULTIFACTOR
Решения вроде MULTIFACTOR демонстрируют эволюционный путь от простых кодов к контекстно‑зависимой аутентификации. Система работает как отдельный слой аутентификации, не вмешиваясь в логику целевых приложений (1С, VPN, корпоративные порталы).
Ключевые элементы архитектуры:
Разделение потоков: проверка логина и пароля остаётся в инфраструктуре заказчика, второй фактор обрабатывается через внешний сервис.
Инициация через API: запрос на второй фактор запускается защищаемой системой с использованием служебных параметров (API Key и секрет), привязанных к организации. Без доступа к внутренней инфраструктуре злоумышленник не сможет корректно инициировать проверку.
Поддержка разных каналов: подтверждение может выполняться через мобильное приложение, пуш, Telegram, eXpress, звонок или СМС. При этом наиболее устойчивы к фишингу методы, где подтверждение происходит на привязанном устройстве, а не через передаваемый код.
Гибридная модель: облачная часть отвечает за политики и обработку запросов, компоненты на стороне заказчика обеспечивают интеграцию с конкретными сервисами.
Дополнительные меры защиты: контроль IP‑адресов, белые и чёрные списки, ограничения по времени доступа, антифрод‑правила. Они не исключают риски полностью, но помогают выявлять аномалии и снижать вероятность успешной атаки.
Интеграция с корпоративными системами (включая те, которые изначально не поддерживают MFA) реализуется через адаптеры и плагины - например, отдельный модуль для 1С добавляет шаг подтверждения второго фактора в процесс аутентификации.
Практические выводы для корпоративной безопасности
Переход к Phishing‑Resistant MFA - это не просто выбор нового фактора, а изменение архитектуры аутентификации: от передачи секретов к криптографическому подтверждению владения ключом. Такой подход существенно усложняет атаки, основанные на фишинге и проксировании аутентификации. Даже при взаимодействии с поддельным интерфейсом злоумышленник не получает пригодный для использования второй фактор.
Однако внедрение требует пересмотра существующих процессов доступа и интеграции с корпоративной инфраструктурой. Важно не ограничиваться одним механизмом, а применять комплексный подход: использовать криптографические методы, разделять каналы подтверждения, устранять уязвимости в «легаси»‑компонентах и дополнять защиту антифрод‑правилами и контролем контекста доступа. Именно в этом направлении будет развиваться корпоративная аутентификация в ближайшие годы.