MFA и 2FA: почему разница в одном факторе меняет всё

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

, а реальная защита зависит от тонких деталей реализации, о которых почти не говорят в методичках».

Не одно и то же: путаница в определениях

Первое, с чем сталкиваются специалисты — терминологическая каша. 2FA (двухфакторная аутентификация) и MFA (многофакторная аутентификация) в бытовом общении часто используются как синонимы, но между ними есть техническое различие. 2FA, это частный случай MFA, который строго требует именно два разных фактора. Если система запрашивает пароль (знание), а затем код из SMS (владение), это 2FA. MFA — более общее понятие: аутентификация может использовать два, три или более факторов. Например, доступ к критичному контуру может требовать пароль, физический токен и сканирование отпечатка пальца.

Глубина путаницы простирается дальше. Некоторые стандарты, такие как требования регуляторов к защите персональных данных, формально могут требовать «многофакторности», но на практике довольствуются двумя факторами. Это создаёт риски, когда реализация, формально соответствующая норме, использует два слабых фактора одного типа (например, пароль и контрольный вопрос — оба из категории «знание»), что не даёт полноценной защиты. Понимание этой разницы — основа для грамотного проектирования и аудита.

Анатомия факторов: что на самом деле учитывается

Классическая модель делит факторы на три категории:

  • Знание (Something you know). Пароль, PIN-код, ответ на секретный вопрос.
  • Владение (Something you have). Физический токен (например, eToken или JaCarta), смартфон с приложением-аутентификатором, SIM-карта для SMS.
  • Биометрия (Something you are). Отпечаток пальца, сканирование лица, рисунок вен ладони, голос.

В последние годы к ним добавились менее очевидные, но набирающие силу категории:

  • Местоположение (Somewhere you are). Геолокация по IP-адресу или данным сотовой сети. Если попытка входа происходит из региона, нехарактерного для пользователя, доступ может блокироваться даже при корректных пароле и коде.
  • Поведенческие паттерны (Something you do). Анализ манеры набора текста, скорости движения мыши, типичного времени активности. Этот фактор часто работает в фоновом режиме, не требуя явных действий от пользователя.

Для соответствия требованиям 2FA или полноценного MFA факторы должны быть независимыми. Использование двух паролей или пароля и контрольного вопроса, это всё один фактор «знания», что не даёт нужного уровня безопасности.

Как это работает изнутри: протоколы и их уязвимости

Когда вы вводите код из приложения после пароля, в фоне запускается сложный механизм. Для генерации одноразовых кодов чаще всего используется два открытых стандарта: TOTP (Time-based One-Time Password) и HOTP (HMAC-based One-Time Password).

TOTP — самый распространённый. Его принцип в том, что и сервер, и ваше устройство (например, приложение Google Authenticator или Yandex Key) знают один общий секретный ключ. Код генерируется на основе этого ключа и текущего времени, округлённого до интервалов (обычно 30 секунд). Именно поэтому код постоянно меняется. Уязвимость здесь — в синхронизации времени. Если часы на сервере или телефоне уйдут вперёд или отстанут больше чем на интервал, аутентификация может не сработать. Другая проблема — если секретный ключ каким-то образом будет скомпрометирован при первоначальной настройке (например, перехвачен через фишинг), то злоумышленник сможет генерировать те же самые коды.

HOTP работает на основе счётчика, который увеличивается после каждого использования. Он менее распространён для онлайн-сервисов, но часто применяется в физических токенах, где нет надёжной синхронизации времени. Риск — возможная рассинхронизация счётчика между клиентом и сервером, если кнопка на токене была нажата случайно несколько раз без попытки входа.

Протоколы вроде WebAuthn (FIDO2) подходят иначе. Здесь не используется общий секрет. Вместо этого на устройстве пользователя (например, в аппаратном ключе безопасности или смартфоне с TPM-чипом) создаётся уникальная криптографическая пара ключей. При регистрации открытый ключ отправляется на сервер, а приватный никогда его не покидает. При входе сервер отправляет «вызов» (challenge), который устройство подписывает приватным ключом. Сервер проверяет подпись с помощью открытого ключа. Такой подход значительно безопаснее, так как исключает перехват общего секрета и устойчив к фишингу — подпись валидна только для конкретного домена сайта.

Почему SMS, это слабое звено, а не полноценный фактор

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

Уязвимости SMS носят системный характер:

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

Ключевой момент: SMS относится к фактору «владения» (у вас есть SIM-карта), но канал его доставки крайне ненадёжен. Поэтому в строгих требованиях безопасности SMS либо не учитывается как полноценный второй фактор, либо его использование допускается только в комбинации с более сильными методами для MFA с тремя и более факторами.

MFA в контексте регуляторики: ФСТЭК и 152-ФЗ

В российском правовом поле MFA из технологической рекомендации превратился в обязательное требование для целого ряда систем. Основные документы — приказы ФСТЭК России.

Например, базовые требования к защите персональных данных (совпадающие по сути с требованиями 152-ФЗ) содержат положение о необходимости «применения двухфакторной аутентификации» для удалённого доступа к информационным системам, содержащим персональные данные. Формулировка прямо указывает на 2FA, а не на общее MFA. При этом часто подразумевается, что одним из факторов должен быть аппаратный (физический токен, сертифицированный по требованиям ФСТЭК или ФСБ), особенно для систем с высоким уровнем защищённости.

Для государственных информационных систем и систем критической информационной инфраструктуры (КИИ) требования жёстче. Здесь может прямо предписываться использование средств криптографической защиты информации (СКЗИ), встроенных в процесс аутентификации. Фактически это означает, что вторым фактором должен выступать не просто код из приложения, а электронная подпись, созданная с использованием сертифицированного токена (например, JaCarta, eToken). Это выводит MFA из плоскости удобства в плоскость юридически значимой идентификации.

Важный нюанс для аудита: недостаточно просто проверить галочку «2FA включён». Нужно анализировать:

  • Используемые факторы на предмет их независимости и соответствия уровню защищённости системы.
  • Применяются ли сертифицированные средства (для КИИ и ГИС).
  • Настроены ли политики блокировки при множественных неудачных попытках ввода кода (защита от подбора).
  • Обеспечивается ли безопасное хранение и передача секретов (ключей TOTP) при инициализации.

Человеческий фактор и практические ловушки

Даже идеально спроектированная MFA-система спотыкается о поведение пользователей.

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

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

Проблема восстановления. Процедура сброса MFA при утере устройства — часто самое слабое место. Если восстановление возможно только через обращение в службу поддержки по телефону с ответами на контрольные вопросы (фактор «знание»), то вся многофакторная защита сводится на нет одной социальной атакой.

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

Будущее: куда движется аутентификация

Эволюция MFA идёт в сторону устранения самого слабого звена — человека, которому нужно что-то помнить или делать. Тренд — беспарольная аутентификация (Passwordless).

Это не отказ от факторов, а их переосмысление. Вместо пароля используется комбинация, например, фактора «владения» (аппаратный ключ FIDO2 или смартфон) и фактора «биометрии» (отпечаток для разблокировки этого ключа). Пользователь просто прикладывает палец и вставляет ключ в USB-порт — доступ получен. Никаких паролей или кодов для запоминания.

Другой вектор — адаптивная и непрерывная аутентификация. Система не запрашивает подтверждение разово при входе, а постоянно анализирует контекст сессии: ритм печати, активность мыши, местоположение, используемые приложения. При обнаружении аномалий (например, пользователь, только что работавший из офиса в Москве, вдруг пытается скачать базу данных, находясь «условно» в другом регионе) система может запросить дополнительное подтверждение или тихо заблокировать сессию, отправив оповещение администратору.

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

Оставьте комментарий