MAATRIX / Блог / Миф: двухфакторка по SMS — надёжная защита

Миф: двухфакторка по SMS — надёжная защита

MAATRIX

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

Что в этом мифе правда

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

Так что миф не в том, что "SMS-2FA бесполезна" — она полезна против широкого класса дешёвых, нецелевых атак. Миф в другом: что SMS-2FA настолько же надёжна, насколько TOTP-приложение или аппаратный ключ, и что её можно считать современным эталоном второго фактора. Против целенаправленной атаки на конкретного человека или аккаунт с достаточной ценностью SMS — самое слабое звено из всех распространённых методов MFA.

SIM-swap: перехват номера без физического доступа к телефону

Самая практичная и массово эксплуатируемая слабость SMS-2FA — это не взлом протоколов связи, а социальная инженерия против сотового оператора. Атакующий, заранее собравший о жертве минимум личных данных (частично из открытых источников, частично из слитых баз, частично — просто угадав типовые ответы на контрольные вопросы), обращается в салон связи или в поддержку оператора и убеждает их перевыпустить SIM-карту жертвы на карту, физически находящуюся у него — под предлогом "потерял телефон" или "сломалась SIM".

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

Ключевая деталь: SIM-swap не требует ни физического доступа к телефону жертвы, ни компрометации её устройства, ни знания пароля от аккаунтов. Это атака на процесс сотового оператора, а не на криптографию или на само устройство — стоимость такой атаки для злоумышленника фиксированная и не зависит от сложности пароля жертвы. Именно поэтому она особенно опасна для людей с публичной или предсказуемой цифровой личностью — крипто-инвесторов, администраторов инфраструктуры с доступом к деньгам или чувствительным системам.

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

Нужен сервер под эту задачу?

Разверните VPS MAATRIX за пару минут: NVMe, AMD EPYC, root-доступ, локации UK, США, Франция и РФ. Оплата картой РФ и по СБП.

Арендовать сервер

SS7 и перехват SMS на уровне сети оператора

Второй, менее массовый, но структурно даже более тревожный класс атак — это не социальная инженерия, а уязвимости в самом протоколе сигнализации, на котором исторически построена телефонная сеть, — SS7 (Signaling System 7). Протокол разрабатывался в эпоху, когда сеть операторов считалась закрытым доверенным контуром, и в нём исторически не заложены механизмы строгой проверки того, что запрос на маршрутизацию SMS или звонка действительно приходит от легитимного оператора, а не от стороны, получившей доступ к сигнальной сети.

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

Важный вывод: слабость SMS-2FA не гипотетическая и не единичная, а системная — она лежит одновременно на уровне человека в салоне связи (SIM-swap) и на уровне протокола сигнализации сети (SS7). Устранить оба уровня усилиями конечного пользователя невозможно — вы не можете "настроить" телефон так, чтобы он стал устойчив к перехвату SMS на уровне чужой инфраструктуры, которой вы не управляете.

SMS зависит от сети — а сеть не гарантирована

Отдельная, менее драматичная, но практически куда более частая проблема SMS-2FA — банальная зависимость от доступности сотовой связи в момент, когда код нужен. Код на карту, а не в приложение — и вот конкретные ситуации, где это оборачивается блокировкой доступа:

  • Роуминг за границей. Роуминг может быть отключён намеренно (экономия), недоступен в конкретной стране, или работать с задержкой в десятки секунд-минут — а форма входа часто ограничивает время жизни кода 5 минутами.
  • Зона без покрытия. Подвал, лифт, загородный дом, поезд в туннеле, самолёт — код в моменте недоступен вообще, независимо от того, как срочно нужен доступ.
  • Смена SIM или потеря телефона без резервного номера. Если единственный способ получить код — SMS на конкретную карту, а карта потеряна или ещё не активирована после переезда, восстановление доступа превращается в квест через поддержку сервиса.
  • Задержки у оператора/агрегатора SMS. У сервисов, рассылающих коды через SMS-агрегаторов, случаются периоды деградации доставки — код может прийти через 10-15 минут вместо 10-15 секунд, когда сессия входа уже истекла.
  • Спам-фильтрация. Операторы или сами телефоны при агрессивных настройках фильтра иногда помечают SMS с кодами как подозрительные и режут доставку — предсказать это заранее нельзя.

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

TOTP-приложения: что меняется и что остаётся уязвимым

TOTP (Time-based One-Time Password) — это алгоритм, при котором и сервис, и ваше приложение-аутентификатор (Google Authenticator, Aegis, Authy, встроенный менеджер паролей с поддержкой TOTP) независимо друг от друга генерируют один и тот же одноразовый код на основе общего секретного ключа и текущего времени, без какого-либо сетевого обмена в момент генерации кода. Секретный ключ передаётся один раз, в момент привязки (обычно через QR-код), и дальше хранится только на двух сторонах — на сервере и в приложении на вашем устройстве.

Что это устраняет из проблем SMS-2FA:

  • SIM-swap перестаёт быть вектором атаки на этот фактор. Секрет TOTP не привязан к номеру телефона и не проходит через сотового оператора вообще — перевыпуск SIM-карты никак не помогает получить код.
  • SS7 и подобные сетевые атаки неприменимы. Код не передаётся по сети телефонной сигнализации — его попросту не существует нигде, кроме момента генерации на двух заранее синхронизированных сторонах.
  • Не нужна сотовая сеть в момент входа. Приложение генерирует код локально по системным часам устройства — работает в самолёте, в метро, за границей без роуминга.

Что TOTP не решает:

  • Фишинг в реальном времени. Если жертва вводит и пароль, и текущий TOTP-код на поддельной странице, а атакующий тут же, за секунды, ретранслирует их на настоящий сайт (атака "adversary-in-the-middle" через прокси-фишинг), сессия может быть перехвачена — TOTP защищает от повторного использования кода позже, но не от мгновенной ретрансляции в момент ввода.
  • Кражу самого секрета/устройства. Если телефон с аутентификатором украден и разблокирован (либо секрет TOTP скомпрометирован через незашифрованный бэкап), у атакующего появляется возможность генерировать коды самому.
  • Восстановление при потере устройства. Без резервных кодов, сохранённых отдельно, потеря телефона с TOTP-приложением означает процедуру восстановления через поддержку сервиса — этот сценарий стоит продумать заранее.

Аппаратные ключи FIDO2/U2F: следующий уровень

Аппаратные ключи (YubiKey и аналоги, работающие по стандартам FIDO2/WebAuthn или более раннему U2F) устраняют ещё один класс атак, перед которым TOTP бессилен, — фишинг в реальном времени. Механизм другой: при регистрации ключ создаёт уникальную криптографическую пару для конкретного домена сайта, и при последующей аутентификации браузер и ключ вместе проверяют, что домен запроса совпадает с тем, для которого создавалась пара. Если пользователь попал на поддельную страницу с похожим, но другим доменом, ключ откажется подписывать запрос — сравнение доменов происходит на уровне протокола, автоматически, без возможности "случайно" ошибиться, в отличие от визуальной проверки адресной строки человеком.

Практические следствия такой конструкции:

  • Секрет (приватный ключ) физически не покидает сам аппаратный токен — украсть его удалённо, через сеть, программно, невозможно в принципе; нужен физический доступ к самому ключу.
  • Фишинговая страница, даже идеально скопированная визуально, не может обманом получить подпись для чужого домена — привязка к домену встроена в протокол, а не зависит от внимательности пользователя.
  • Без физического обладания ключом второй фактор пройти нельзя вообще — ни SIM-swap, ни компрометация сети, ни кража одного лишь пароля к этому не приводят.

Обратная сторона — это физический объект, который можно потерять, забыть дома, уронить в воду. Поэтому практика для серьёзных аккаунтов — регистрировать минимум два ключа (основной и резервный, хранящийся отдельно, например в сейфе или у доверенного человека), а не полагаться на единственный физический токен. Для панелей управления инфраструктурой — хостинг-аккаунтов, панелей VPS, DNS-регистраторов — там, где поддерживается FIDO2/U2F, это по совокупности защищённости и удобства сейчас лучший выбор из массово доступных методов; обзор того, что и как стоит защищать вторым фактором на уровне панелей управления — в статье двухфакторная аутентификация для панелей управления.

Сравнение методов и когда SMS всё же оправдана

МетодУстойчив к SIM-swapУстойчив к SS7-перехватуРаботает без сетиУстойчив к фишингу в реальном времениТребует отдельного устройства
SMS-кодНетНетНетНетНет (сам телефон)
Push-уведомление в приложении банка/сервисаЧастично*Частично*Нет (нужен интернет)ЧастичноНет
TOTP-приложение (Google Authenticator, Aegis и т.п.)ДаДаДаНетНет
Аппаратный ключ FIDO2/U2FДаДаДаДаДа

\* Push-уведомления идут через интернет, а не через SMS-канал оператора, поэтому SIM-swap и SS7 напрямую на них не влияют — но они зависят от привязки к устройству и аккаунту в экосистеме сервиса, и здесь возможны свои сценарии социальной инженерии ("MFA fatigue" — заваливание пользователя push-запросами в надежде, что он подтвердит один по невнимательности).

При этом важно не впадать в другую крайность и не считать SMS-2FA бесполезной. Есть конкретные ситуации, где она остаётся разумным выбором:

  • Как временная мера, пока не настроен TOTP или ключ. Включённая SMS-2FA прямо сейчас лучше отложенной идеальной защиты "как-нибудь потом".
  • Как запасной канал восстановления доступа, второй по счёту после основного TOTP или ключа, а не единственный метод — на случай утери телефона с приложением-аутентификатором.
  • Для аккаунтов с низкой ценностью и низкой вероятностью целевой атаки, где угроза — это массовые нецелевые попытки входа по слитым паролям, а не решительный злоумышленник, готовый тратить время и деньги на SIM-swap конкретно против вас.
  • Когда сервис в принципе не предлагает других вариантов — к сожалению, до сих пор часть банков и государственных сервисов поддерживает только SMS как второй фактор, и здесь выбора у пользователя просто нет.

Для всего, что связано с деньгами напрямую (банк, биржа, криптокошелёк), с инфраструктурой (панели хостинга, SSH, DNS, репозитории кода) или с единой точкой восстановления других аккаунтов (основная почта) — SMS не должна быть единственным или основным фактором, если у сервиса есть альтернатива.

Нужен сервер под эту задачу?

Разверните VPS MAATRIX за пару минут: NVMe, AMD EPYC, root-доступ, локации UK, США, Франция и РФ. Оплата картой РФ и по СБП.

Арендовать сервер

Нужны сами нейросети для контента?

Генерируйте изображения, видео и озвучку нейросетями на falapi.io — десятки моделей в одном окне. Оплата картой РФ и по СБП.

Частые вопросы

Если у меня уже включена SMS-2FA, стоит ли её выключать?

Нет, не выключайте её просто так — оставьте как резервный канал, но добавьте TOTP-приложение или ключ как основной метод входа там, где сервис это позволяет, и переключите приоритет на него.

Можно ли перевести номер на eSIM, чтобы защититься от SIM-swap?

Это не решает проблему — SIM-swap эксплуатирует процесс переноса номера у оператора, а не физический носитель карты; eSIM так же подвержена перевыпуску по звонку в поддержку, как и обычная SIM.

Что делать, если я узнал о SIM-swap постфактум?

Немедленно связаться с оператором для возврата номера и параллельно, не дожидаясь решения вопроса с номером, сменить пароли и отвязать телефон как метод восстановления во всех критичных аккаунтах (почта, банк, биржи) — счёт может идти на минуты.

TOTP-секрет хранится в облаке моего менеджера паролей — это безопасно?

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

Насколько распространены SIM-swap и SS7-атаки на практике для рядового пользователя?

Массовые нецелевые атаки на пароли (утечки, подбор) на порядки более вероятны для обычного человека, чем целевой SIM-swap — последний оправдан для атакующего экономически только против заметно ценной цели. Но если вы администрируете инфраструктуру, держите крипто-активы или иным образом представляете интерес как цель, стоит закладывать именно этот сценарий в модель угроз заранее, а не постфактум.

Обсудить статью, задать вопрос или начать новую тему

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

Перейти в сообщество →