Двухфакторная аутентификация в цифрах: что показывают данные отчетов безопасности

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

Двухфакторная аутентификация снижает этот риск. Не отменяет его. В исследовании Microsoft Research MFA уменьшила риск компрометации коммерческих аккаунтов Azure Active Directory на 99,22% по изученной популяции. Для аккаунтов, чьи данные уже фигурировали в утечках, снижение составило 98,56%. Показатель сильный. Превращать его в обещание «защиты на 99%» для любого сервиса нельзя.

Проблема не в самой идее 2FA. Проблема в неоднородности факторов, recovery-процессов, session management и интеграции identity provider с прикладными системами. Код из SMS, TOTP в приложении, push approval и FIDO2 security key формально относятся к MFA. Их устойчивость к реальным атакам различается принципиально.

Реальная эффективность MFA: границы цифры 99,22%

Microsoft Research опубликовала результаты в мае 2023 года. В исследованной популяции коммерческих аккаунтов Azure Active Directory более 99,99% учетных записей с включенной MFA остались защищенными в период наблюдения. Риск компрометации снизился на 99,22%.

Эти значения нужно читать корректно.

Во-первых, речь идет об аккаунтах в конкретной identity ecosystem. Там работают собственные механизмы conditional access, risk detection, telemetry, throttling, password protection и сигналы о подозрительных входах. Переносить результат один к одному на self-hosted IAM, старый корпоративный портал или мобильное приложение без централизованного IdP нельзя.

Во-вторых, метрика отражает снижение риска компрометации учетной записи, а не устранение всех классов атак. MFA не закрывает:

• кражу активной web-сессии через infostealer или reverse-proxy phishing;
• компрометацию endpoint, где уже открыта корпоративная сессия;
• ошибочный recovery flow с низкими требованиями к верификации;
• захват телефонного номера через SIM swap;
• approval fraud при push bombing;
• действия администратора с избыточными правами;
• OAuth consent phishing и выдачу токена вредоносному приложению;
• обход через legacy authentication, если он не отключен.

Для аккаунтов с известной утечкой пароля Microsoft зафиксировала снижение риска на 98,56%. Это практическая цифра для оценки credential stuffing. Если пароль уже есть в чужой базе, второй фактор резко сокращает ценность этой базы для атакующего. Но только при условии, что фактор нельзя перехватить в момент входа или продавить через пользователя.

MFA снижает ценность украденного пароля. Она не снижает ценность слабого процесса восстановления доступа.

В аналитике использования 2FA в компаниях ключевой вопрос не «включена ли MFA». Вопрос другой: какая доля привилегированных, внешних и обычных учетных записей использует фишинг-устойчивый фактор и насколько изолированы исключения.

Типичная ошибка отчетности — считать покрытие по числу пользователей. Архитектурно корректнее считать по risk surface:

• отдельное покрытие для Global Administrator, tenant administrator, DevOps и security roles;
• покрытие внешнего доступа: VPN, VDI, SaaS, SSO portal;
• покрытие сервисных аккаунтов и workload identities;
• доля пользователей с SMS, TOTP, push и FIDO2/passkeys;
• доля legacy protocols без modern authentication;
• доля recovery-сценариев, где пароль можно сбросить без phishing-resistant verification;
• среднее время от регистрации нового фактора до отзыва старого.

Показатель «MFA enabled: 96%» без этой декомпозиции мало пригоден. Он не показывает, какие 4% остались вне политики и обладают ли они правами на изменение конфигурации tenant.

Credential stuffing: почему уникальный пароль не стал нормой

В Verizon DBIR 2025 скомпрометированные учетные данные указаны как начальный вектор в 22% рассмотренных утечек. Дополнительный анализ SSO-логов показывает другую операционную проблему: credential stuffing составляет медианно 19% всех ежедневных попыток аутентификации. В крупных компаниях медианное значение достигает 25%. У малого бизнеса — 12%.

Это нагрузка не только на SOC. Это нагрузка на identity plane.

Credential stuffing работает на повторном использовании паролей. В данных Verizon медианная доля уникальных паролей одного пользователя между разными сервисами составила лишь 49%. Остальная часть пересекается с другими учетными записями. Достаточно одной утечки на внешнем сервисе, чтобы пароль стал входным материалом для автоматизированной проверки в корпоративных системах.

У злоумышленника нет необходимости угадывать пароль. Достаточно получить комбинации email:password, проверить их через botnet, обойти слабый rate limiting и найти сервис без второго фактора или с уязвимым recovery flow.

Двухфакторная аутентификация меняет экономику атаки. Массовая проверка логинов перестает быть достаточной. Атакующему требуется дополнительный этап: перехват OTP, подмена SIM, убеждение пользователя одобрить push или кража session cookie. Стоимость операции растет. Массовый поток превращается в целевую атаку.

Но сама MFA не заменяет базовую защиту authentication endpoint. Нужны:

1. Rate limiting и adaptive throttling. Ограничения должны учитывать не только IP, но и fingerprint, ASN, географию, частоту ошибок, историю устройства и поведение сессии. Лимит по одному IP не работает против распределенной инфраструктуры.

2. Bot detection. Credential stuffing выполняется браузерной автоматизацией, headless-клиентами и residential proxy. WAF без поведенческих сигналов фиксирует только часть трафика.

3. Запрет legacy authentication. IMAP, POP, SMTP AUTH и старые client flows могут обходить policy, рассчитанную на modern auth. Если протокол не поддерживает MFA или conditional access, его место — в inventory исключений с планом удаления.

4. Password hygiene без принудительной ротации по календарю. Смена пароля каждые 30–90 дней не компенсирует reuse. Приоритет — password manager, блокировка известных скомпрометированных паролей и обнаружение password spray.

5. Контроль сессий. Захват cookie после успешной MFA обходит повторный ввод фактора. Нужны device binding, token protection, conditional access и ограниченные session lifetime для чувствительных контуров.

NIST: два фактора не равны защите от фишинга

В NIST SP 800-63B-4, опубликованном в июле 2025 года, разделение проведено жестко. Есть обычная MFA. Есть phishing-resistant authentication. Это разные уровни защиты.

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

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

NIST прямо не считает ручной ввод одноразового кода phishing-resistant authentication. Это относится к TOTP, SMS-кодам и другим out-of-band-кодам. Типичный шестизначный код подтверждает доступ к каналу доставки. Он не подтверждает, что пользователь взаимодействует именно с подлинным relying party.

WebAuthn/FIDO2 решает другую задачу. Аутентификатор криптографически привязывает операцию к имени сервиса. Поддельный домен не получает валидную подпись для настоящего домена. Это не абсолютная защита от социальной инженерии и не контроль endpoint security. Но это устранение класса атак с relay одноразового кода.

Таблица не означает, что SMS нужно одномоментно отключить во всех системах. Для части B2C-сервисов SMS остается переходным барьером против массового захвата аккаунтов. Но использовать его как целевую модель для администраторов, финансовых операций, VPN и production-доступа нерационально.

Email как канал доставки одноразового кода NIST относит к недопустимым аутентификаторам. Причина архитектурная: доступ к почте часто защищен тем же паролем, восстановление самого почтового ящика может быть слабее основного сервиса, а почтовый канал подвержен перехвату и перенаправлению. Из этого правила NIST делает отдельное исключение — резервные одноразовые коды восстановления, pre-generated backup codes, которые пользователь получает при регистрации фактора и хранит офлайн. Это самостоятельный механизм, не зависящий от электронной почты, и к out-of-band delivery он не относится.

Код подтверждает доступ к устройству или каналу. FIDO2 подтверждает привязку к конкретному сервису.

Push bombing и Storm-2949: MFA ломается в точке принятия решения

Push MFA удобна для пользователей и недорога в эксплуатации. Ее слабое место — человек, который получает серию запросов на подтверждение.

Модель атаки проста. Злоумышленник располагает паролем. Он инициирует вход многократно. Пользователь получает push-уведомления. Затем атакующий звонит, пишет в корпоративный мессенджер или представляется сотрудником поддержки. Цель — добиться одного подтверждения.

NIST отказался от модели, где пользователь только одобряет запрос во втором канале после сопоставления секрета. Причина — authentication fatigue. CISA также указывает на риски push bombing, SIM swap и атак на SS7 для отдельных методов MFA.

В мае 2026 года Microsoft описала кампанию Storm-2949. В сценарии злоумышленники через социальную инженерию убеждали пользователей завершить мошеннические MFA-подтверждения в процессе self-service password reset. После этого атакующий мог сбросить пароль и удалить существующие методы аутентификации, включая Microsoft Authenticator.

Это не ошибка MFA как технологии. Это дефект связки из четырех компонентов:

• self-service password reset;
• proofing пользователя при восстановлении;
• разрешение на регистрацию и удаление authentication methods;
• отсутствие достаточного контроля над изменениями в identity profile.

Если password reset способен изменить пароль и факторы аутентификации после подтверждения слабым методом, он становится более ценным target, чем обычная login form. В архитектуре IAM reset flow должен оцениваться как privilege escalation path.

Для корпоративной среды минимальный набор защитных мер выглядит так:

• требовать phishing-resistant factor для регистрации нового фактора у привилегированных ролей;
• не разрешать удаление всех существующих методов в рамках одной слабой recovery-сессии;
• вводить delay или дополнительную проверку для критичных изменений authentication methods;
• отправлять независимое уведомление на ранее зарегистрированный канал;
• журналировать операции reset, factor enrollment, factor deletion и изменение recovery data как high-signal события;
• передавать в SIEM корреляционные поля: user ID, device ID, source IP, ASN, geolocation, authentication method, risk level, ticket ID;
• блокировать password reset при high-risk sign-in или аномальном устройстве;
• разделять обычные пользовательские и административные identity.

Последний пункт часто игнорируется. Администратор не должен ежедневно работать под той же учетной записью, которая используется для почты, видеозвонков и SaaS. Отдельная privileged identity с аппаратным ключом сокращает blast radius компрометации обычного рабочего профиля.

Сессия после MFA: недооцененный слой контроля

Даже сильный фактор не гарантирует безопасность после успешного входа. Аутентификация завершается. Начинается управление сессией.

NIST для AAL2 рекомендует общий срок сессии не более 24 часов и тайм-аут неактивности не более одного часа. Для AAL3 рекомендации жестче: не более 12 часов общего времени и 15 минут бездействия. Это не универсальный норматив для каждого мобильного приложения или сайта. Это ориентир для систем, работающих с соответствующими уровнями доверия.

В enterprise-практике session policy должна зависеть от критичности ресурса.

Нельзя применять один TTL для всего tenant. Длинная сессия в почте может быть приемлема при managed device и низком риске. Та же политика для панели управления облачной инфраструктурой создает ненужный риск. Сессия должна быть привязана к контексту: роль, ресурс, тип устройства, уровень доверия сети, география, риск входа, выполняемая операция.

Отдельная проблема — refresh tokens. Команда может построить строгую MFA-политику, но оставить долгоживущие токены без binding к устройству. В такой конфигурации атакующий, получивший токен, использует уже пройденную MFA как исторический факт. В модели угроз это не bypass MFA. Это replay valid session artifact. Результат для бизнеса одинаковый.

Оптимальный стек: не максимальное число факторов, а контролируемая цепочка

Эффективность методов защиты аккаунтов определяется не количеством экранов в login flow. Она определяется тем, сколько независимых барьеров проходит атакующий до получения привилегированной сессии.

Рациональная целевая модель для компании строится в три уровня.

Базовый уровень: массовые пользовательские аккаунты

Задача — снизить эффект credential stuffing и password spray без перегрузки support desk.

Стек:

• централизованный IdP и SSO;
• MFA для всех интерактивных пользователей;
• authenticator app предпочтительнее SMS;
• password manager и блокировка скомпрометированных паролей;
• rate limiting, bot protection, detection аномальных входов;
• запрет legacy authentication;
• инвентаризация исключений.

SMS остается fallback-каналом, если альтернативы пока нет. Но его нужно измерять как технический долг: доля пользователей, доля успешных входов, доля reset flow и доля критичных ролей на SMS.

Усиленный уровень: доступ к внутренним системам и данным

Задача — снизить риск phishing relay и захвата сессии.

Стек:

• passkeys или FIDO2 security keys;
• conditional access по device compliance и risk score;
• managed endpoints для доступа к чувствительным системам;
• reauthentication при смене контекста;
• короткие сессии для VPN, VDI и административных консолей;
• мониторинг token use и impossible travel;
• отдельные правила для unmanaged device.

Passkeys снижают эксплуатационную стоимость по сравнению с обязательной выдачей физического ключа каждому пользователю. Но enterprise rollout требует контроля синхронизации, support policy для смены устройств, резервного метода и совместимости с IdP. Аппаратные ключи остаются оправданными для администраторов, break-glass-аккаунтов и ролей с высокими правами.

Привилегированный уровень: администраторы и критические операции

Задача — исключить слабый фактор из цепочки повышения привилегий.

Стек:

• отдельные privileged accounts;
• минимум два зарегистрированных аппаратных FIDO2-ключа на администратора с тестовой процедурой восстановления;
• step-up authentication перед активацией привилегированной роли;
• короткий lifetime для привилегированной сессии и обязательный reauth при выходе из idle;
• отдельный канал алертов на изменения authentication methods и role assignment;
• журналирование и session recording для административных действий;
• регулярная ротация break-glass-аккаунтов с проверкой работоспособности;
• запрет повседневной активности (почта, браузер, мессенджеры) под привилегированной учетной записью.

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

Что не попадает в стек

Отдельные механизмы часто рекламируются как «дополнительный фактор», но архитектурной ценности не несут:

• captcha как самостоятельный фактор;
• security questions без привязки к криптографическому proofing;
• device recognition по cookie без backend-проверки;
• IP-фильтрация как замена MFA;
• «секретное слово», передаваемое в том же канале, что и логин.

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

Что остается за рамками цифр

Процент успешных атак на учетные записи нельзя свести к одной метрике. За ней стоят разные классы инцидентов: перебор паролей, phishing relay, session hijack, social engineering вокруг recovery, abuse привилегированных ролей. Двухфакторная аутентификация закрывает часть из них полностью, часть — частично, и почти ничего — против захвата устройства или компрометации session artifact после входа.

Эффективность 2FA — это характеристика конкретной связки фактор + recovery + session + endpoint + операционная дисциплина. Не абстрактного свойства «MFA включена». Поэтому в отчетности полезнее показывать, какой процент привилегированных аккаунтов защищен фишинг-устойчивым фактором, какая доля reset flow требует phishing-resistant verification и сколько сессий имеют привязку к устройству. Эти цифры ближе к реальному риску, чем «99%».

NIST в SP 800-63B-4 формализовал разницу между MFA и phishing-resistant authentication. Эффективность методов защиты аккаунтов в ближайшие годы будет измеряться именно этим разрывом. Команды, которые спланировали миграцию на passkeys и FIDO2, сократят его быстрее. Те, кто ограничился SMS и TOTP, останутся в зоне, где формальный второй фактор есть, а защиты от relay — нет.