Двухфакторная аутентификация в банках: почему растет число сбоев

Пользователь проходит штатное подтверждение: вводит SMS-код или нажимает кнопку в push-уведомлении. Если второй фактор не привязан к конкретному домену или контексту запроса, злоумышленник может перехватить результат аутентификации и открыть кабинет с готовой сессией.

Код при этом не взломан, номер телефона настоящий, банк работает штатно. Почему тогда возникают сбои 2FA в мобильном банке? Потому что атаки сместились глубже: от подбора паролей к доставке кодов, подтверждению операций и управлению сессиями. Одновременно OTP-боты и фишинг типа AiTM превратили отдельные попытки обмана в автоматизированный процесс.

Сбой 2FA начинается с канала доставки кода

SMS уязвим из-за модели доверия, а не только из-за перехвата

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

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

Более доступный способ завладеть номером называется SIM-свопинг. Злоумышленник собирает сведения о владельце, пытается пройти процедуру перевыпуска SIM-карты у оператора и получает новую карту с прежним номером. После этого банковские коды приходят уже ему. Владелец счёта может заметить, что сеть пропала, сообщения задерживаются или с номером произошло что-то необычное. Но сама замена SIM не требует от банка дополнительного подтверждения, если он полагается только на SMS.

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

Четырёхзначный OTP содержит 10 000 возможных комбинаций. При корректной серверной защите этого недостаточно, чтобы сделать подбор практически возможным. Но если endpoint допускает много попыток, плохо ограничивает частоту запросов или по-разному отвечает на неверный, истёкший и уже использованный код, автоматизация может превратить короткий код в перебираемый секрет.

Почему не приходит SMS-код подтверждения

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

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

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

OTP-боты превращают одноразовый код в элемент конвейера

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

Типичная цепочка выглядит так:

1. Пользователь открывает фишинговую страницу и вводит учётные данные.

2. Бот инициирует запрос настоящего кода у банка через привычный клиенту канал.

3. Голосовой или текстовый сценарий убеждает человека сообщить код либо подтвердить действие.

4. Полученное значение передаётся оператору, который использует его для входа или подтверждения операции.

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

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

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

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

AiTM крадёт не пароль, а право действовать от имени клиента

AiTM, или Adversary-in-the-Middle, использует промежуточный сервер. Фишинговый reverse-proxy принимает запросы пользователя и одновременно передаёт их настоящему сайту банка. В результате страница входа и процесс подтверждения могут выглядеть подлинно, но пользователь вводит данные на домене посредника.

Риск особенно высок для факторов, которые не привязаны криптографически к адресу сайта. SMS-код, одноразовый пароль из приложения или push-подтверждение без привязки к origin могут пройти через посредника вместе с остальными данными. Получив результат аутентификации, атакующий может завладеть сессионным токеном, cookie или другим маркером авторизации и продолжить работу в кабинете.

Стандартная AiTM-атака с reverse-proxy не перехватывает аутентификацию FIDO2/WebAuthn, если банк правильно реализовал проверку домена. Эти протоколы связывают криптографический ответ с конкретным origin. Домен посредника не пройдёт такую проверку, а закрытый ключ пользователя не подтвердит вход на чужом сайте. Поэтому AiTM эффективен против SMS, TOTP и push без криптографической привязки, но существенно слабее против passkey или аппаратного ключа, корректно настроенного для конкретного домена.

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

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

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

Почему важно быстро разорвать сессию

Украденная сессия даёт злоумышленнику возможность действовать от имени клиента. Чем быстрее её аннулировать, тем меньше времени остаётся на новые операции. Но простое завершение входа не всегда возвращает уже переведённые деньги. Результат зависит от обстоятельств, скорости обращения и правил, применимых к конкретному платежу.

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

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

Ошибки API превращают проверку в формальность

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

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

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

Другой риск связан с валидацией сессии. Токен может продолжать работать после смены устройства, перезапуска приложения или аннулирования банковской сессии. Если сервер не проверяет его состояние и срок действия, украденный или переданный маркер авторизации сохраняет силу.

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

Устойчивый сценарий проверки OTP должен учитывать несколько вещей:

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

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

Почему цифры фиксируют рост угрозы, но не число взломов

По данным Банка России, антифрод-системы кредитных организаций в 2024 году предотвратили 72,17 млн попыток несанкционированного списания средств против 34,77 млн годом ранее. Совокупный показатель вырос примерно вдвое.

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

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

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

Ru-Center оценивает, что 68% компаний, подключивших 2FA, используют SMS как наименее защищённый канал. Эти данные относятся к корпоративному сегменту, их нельзя напрямую переносить на клиентов банков. Но они показывают, почему отметка «двухфакторная аутентификация включена» сама по себе мало говорит о надёжности защиты.

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

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

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

Что должен изменить банк

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

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

3. Проверять всё на сервере. Backend должен независимо проверять код, устройство, сессию и операцию, а не доверять ответу клиентской части. Ограничение частоты запросов стоит привязывать к нескольким признакам, а повторное использование токена или OTP блокировать.

4. Контролировать срок жизни сессии. Чувствительные действия требуют повторной аутентификации. При необходимости банк может завершать связанные сессии после смены устройства или других событий риска. Для клиента должны быть доступны список активных входов и возможность быстро завершить подозрительные.

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

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

Банковская 2FA не стала бесполезной. Она перестала быть самостоятельной гарантией безопасности. SMS остаётся удобным, но слабо подтверждает личность; push может быть надёжным или уязвимым в зависимости от реализации; FIDO2 лучше защищает от фишинга, если банк верно связывает ответ с доменом и не оставляет обходной путь через восстановление. Поэтому оценивать защиту нужно по всей цепочке, от первого запроса до завершения сессии и подтверждения конкретного перевода.