SMS OTP (одноразовый пароль по SMS) по-прежнему остается одним из самых распространенных способов добавления второго фактора аутентификации. Этот метод знаком пользователям, широко поддерживается и относительно прост в интеграции, поэтому он остается выбором по умолчанию для многих приложений.
83% взрослых жителей США, использующих MFA (многофакторную аутентификацию), получают код по SMS, в то время как one-third of consumers say they avoid MFA because they find it inconvenient. Большинство попыток улучшить этот пользовательский опыт сосредоточены на скорости доставки и конверсии. Возникает другой вопрос: нужно ли вообще генерировать и доставлять видимые пользователю учетные данные в процессе аутентификации?
Именно в этом заключается разница между Silent Authentication и OTP.
Вместо создания кода и его отправки по цепочке доставки SMS, Silent Authentication проверяет владение номером телефона через мобильную сеть. Пользователю не нужно получать, копировать или отправлять учетные данные.
В этой статье рассматривается данная разница с точки зрения конфиденциальности и архитектуры.
SMS OTP отправляет учетные данные через четырех посредников, прежде чем они дойдут до вас. Silent Authentication никогда их не генерирует. Меньше переходов. Выше конфиденциальность.
Цена конфиденциальности для SMS OTP
OTP создает учетные данные, которые должны передаваться по сети.
Это звучит абстрактно, поэтому приведем конкретный пример. Когда ваше приложение отправляет OTP по SMS, код проходит через несколько систем, прежде чем попасть на устройство пользователя. Он следует по цепи:
Каждая передача — это точка потенциальной уязвимости. Код существует в виде читаемого значения в нескольких точках этой цепи, и ваше приложение не имеет ни видимости, ни контроля над большинством из них.
SS7 — это протокол, по которому маршрутизируется большая часть мирового трафика SMS. Он восходит к 1970-м годам и был разработан задолго до того, как современное сквозное шифрование стало общепринятым. Исследователи неоднократно демонстрировали реальные перехваты SMS OTP «в дикой природе». В 2017 году злоумышленники приобрели доступ к SS7 у зарубежного оператора связи, использовали его для перенаправления OTP немецких банковских клиентов на телефоны, контролируемые ими, и опустошили их счета. O2 Telefónica подтвердила факт этой атаки.
Смена SIM-карты (SIM-swapping) — еще один вектор атаки: поскольку контроль над номером телефона рассматривается как доказательство владения, злоумышленник, использующий методы социальной инженерии против службы поддержки оператора, может полностью обойти ваш OTP. API Vonage SIM Swap Insight предоставляет сигнал именно для такого случая, но это уровень обнаружения поверх существующей уязвимости, а не ее исправление. Злоумышленникам даже не нужно ничего перехватывать — они просто перенаправляют доставку на свое собственное устройство.
Смишинг (SMS-фишинг) более изощрен, но, пожалуй, наносит больший ущерб в больших масштабах. SMS OTP формирует у пользователя модель поведения, которую могут имитировать фишинговые атаки: получение кода и запрос на выполнение определенных действий. Это делает процесс аутентификации более легким для воспроизведения в атаках с использованием социальной инженерии. Фишинговое сообщение не обязательно должно быть сложным. Пользователь уже приучен к такому сценарию.
Перехват SS7 — не самая вероятная угроза для каждого приложения. Архитектурный вопрос гораздо уже: если верификация может работать без генерации видимых пользователю учетных данных, нужно ли по-прежнему создавать и передавать их?
Как работает Silent Auth (и чем она не является)
OTP генерирует секрет, доставляет его пользователю и просит вернуть его обратно. Silent Authentication действует иначе. Она проверяет, совпадает ли SIM-карты в устройстве с проверяемым номером телефона. Код подтверждения, видимый пользователю, не создается, и пользователю не нужно переписывать или отправлять какое-либо значение.
Запрос рабочего процесса выглядит следующим образом при инициировании проверки Silent Auth через Vonage Verify API:
API отвечает ссылкой check_url. Ваш мобильный клиент открывает эту ссылку через сотовое соединение устройства. Оператор перехватывает запрос, проверяет, соответствует ли SIM-карта в устройстве номеру телефона в запросе, и возвращает результат. Ваш сервер опрашивает систему на предмет результата:
Никаких кодов пользователю не отправлялось. Проверка происходила полностью внутри сети оператора.
Один из контраргументов, который стоит воспринимать всерьез: «У Silent Auth все равно есть внутренний код. Это не совсем система без учетных данных». Технически это верно. Во внутреннем синхронном потоке присутствует внутренний токен. Но этот токен никогда не попадает в контролируемую пользователем среду. Он не попадает во входящие сообщения, не появляется на экране блокировки и не задерживается в буфере обмена. Здесь нет уведомления, которое может скопировать фишинговая страница, и пользователю нечего случайно назвать вслух под влиянием обмана. Различие, имеющее значение для конфиденциальности, заключается не в том, существует ли токен внутри системы, а в том, существует ли он там, где человека можно обмануть и заставить его отдать этот токен.
Минимизация данных: принцип, объединяющий все это
Минимизация данных — это идея о том, что вы собираете и генерируете только то, что необходимо для выполнения задачи. Это принцип, а не жесткое правило, но он имеет юридическую силу. В GDPR Article 5(1)(c) указано, что персональные данные должны быть «адекватными, релевантными и ограниченными тем, что необходимо».
OTP противоречит цели минимизации данных, поскольку создает дополнительные конфиденциальные значения, которые необходимо транспортировать и защищать. Вы генерируете учетные данные, которые затем требуют защиты при передаче. Накладные расходы на обеспечение безопасности — это не отдельное проектное решение. Они являются прямым следствием самого факта создания учетных данных. Как только приложение создает эти учетные данные, оно также берет на себя ответственность за их защиту по всей инфраструктуре доставки, над которой у него есть лишь частичный контроль.
Silent Authentication не требует таких компромиссов. Не потому, что она была разработана специально для соответствия GDPR, а потому, что отсутствие генерации ненужных данных — это просто хороший инжеринговый подход. Соответствие требованиям конфиденциальности согласно Статье 5(1)(c) является побочным эффектом правильной реализации механизма, а не галочкой для соблюдения норм.
Оператор связи уже находился в цепочке аутентификации до того, как вы отправили хотя бы одно OTP. Номер телефона принадлежит оператору. Когда вы добавляете SMS, вы также добавляете агрегатор, который их маршрутизирует, и каждый промежуточный узел между ними. Ни у одной из этих сторон нет юридических или договорных отношений с вашим пользователем. У оператора они есть.
Silent Auth не вводит новую доверенную сторону. Она устраняет те стороны, которым там вообще нечего делать.
Модель доверия операторов связи
Сравнение цепочек доверия делает это очевидным.
При использовании OTP:
Ваше приложение → SMS-провайдер → агрегатор → маршрутизация SS7 → оператор → пользователь
При использовании Silent Auth:
Ваше приложение → Vonage → оператор → результат
Это более короткая цепочка с меньшим количеством участников. Каждый дополнительный узел на пути OTP — это посредник, который соприкасается с учетными данными при их передаче. Оператор связи уже являлся частью отношений мобильной идентификации до появления вашего приложения. Доставка SMS добавляет посредников, которых раньше не было. У оператора есть подписанный договор с абонентом. Абонент сам выбрал оператора. Ничего из этого не относится к агрегаторам, находящимся в цепочке OTP.
Это напрямую отвечает на возражение о доверии. Вы выбираете не между доверием к SMS-провайдеру и доверием к оператору. Вы выбираете между длинной цепочкой, включающей обоих, и короткой цепочкой, включающей только ту сторону, с которой у пользователя уже есть существующие отношения. Оператор присутствует в обоих случаях. Агрегатор — только в одном.
Реализация: используйте Silent Auth в первую очередь, а в качестве резервного варианта применяйте SMS
Стандартная тихая аутентификация (Silent Authentication) требует сотового соединения. Библиотеки Vonage iOS и Android решают эту задачу, принудительно направляя запрос check_url через сотовую сеть, даже если устройство подключено к Wi-Fi. Если сотовая связь недоступна, рабочий процесс автоматически переключается на ваш следующий канал.
Это ограничение снижено в Silent Authentication Advanced (в настоящее время находится на стадии альфа-тестирования), которая использует криптографическое рукопожатие на уровне SIM-карты по стандарту GSMA TS.43 и работает через сотовую связь, Wi-Fi и VPN. Для подключения требуется изменить всего один параметр: добавить «mode»: «advanced» в канал silent_auth в вашем рабочем процессе. Развертывание операторами связи уже идет.
Для стандартной Silent Auth покрытие действует в США, Великобритании, Канаде и Западной Европе. Для приложений, обслуживающих другие регионы, с этим справляется резервный вариант (fallback).
Silent Auth должна быть первой в рабочем процессе. Ее нельзя использовать в качестве резервного варианта для другого канала. После нее вы можете объединять в цепочку любые комбинации SMS, RCS, голосовых вызовов, WhatsApp или электронной почты в зависимости от ваших пользователей и регионов. Полные правила упорядочения каналов приведены в руководстве по Verify Workflow API. SMS — наиболее распространенный выбор благодаря своему охвату; WhatsApp и RCS стоит рассмотреть, если ваши пользователи уже пользуются этими каналами и вы хотите полностью уйти от уровня SS7. Вот типичная конфигурация:
Когда Silent Auth завершается успешно, никакие учетные данные не попадают в пользовательское пространство. При переключении на резервный канал действуют компромиссы выбранного вами канала. Если вы хотите перейти от этих фрагментов кода к работающей реализации, в учебнике по Silent Authentication для Node.js подробно описана настройка сервера и клиента. В этот момент начинают действовать свойства безопасности и конфиденциальности резервного канала.
Если Silent Auth успешна, пользователь попадает на конфиденциальный путь. Если срабатывает резервный вариант, он получает тот же опыт, который у него был бы только с SMS. В любом случае, вы предоставили Silent Auth первый шанс.
Заключение
OTP сочетает в себе проверку владения с заметным для пользователя взаимодействием. Такое взаимодействие привычно и широко поддерживается, но оно также создает данные, которые могут быть перехвачены, перенаправлены, скопированы или подвергнуты социальной инженерии.
Тихая аутентификация (Silent Authentication) одновременно устраняет трение и поверхность атаки. В редком случае беспроигрышной ситуации улучшения безопасности и пользовательского опыта направлены в одну сторону. Удаление видимых пользователю учетных данных снижает как издержки на взаимодействие, так и несколько классов атак.
Индустрия уже движется в этом направлении. NIST recommended against SMS 2FA in 2016. Сингапур, ОАЭ и Индия предприняли шаги по ограничению или запрету SMS OTP в финансовых услугах. Успешная атака на немецкие банки в 2017 году подтвердила, что перехват SS7 — не теория. Несмотря на эти опасения, SMS OTP остается широко используемым инструментом благодаря своему охвату и привычности.
Вам не нужно ждать решения регулятора, чтобы принять архитектурное решение. Инструменты доступны уже сейчас.
Готовы попробовать? Зарегистрируйте учетную запись Vonage API, затем ознакомьтесь с руководством по концепции Silent Authentication и обзором Vonage Verify API.
Дополнительные материалы
- Представляем Vonage Silent Authentication: базовое пояснение — начните отсюда, если вам нужен дополнительный контекст о том, как работает Silent Auth, прежде чем погружаться в статьи по реализации.
Представляем Vonage Silent Authentication: базовое пояснение — начните отсюда, если вам нужен дополнительный контекст о том, как работает Silent Auth, прежде чем погружаться в статьи по реализации.
- Каждому паскэю нужен тихий партнер: как Silent Auth сочетается с паскэями для создания полноценного стека аутентификации.
Каждому паскэю нужен тихий партнер: как Silent Auth сочетается с паскэями для создания полноценного стека аутентификации.
- Улучшите многофакторную аутентификацию с помощью Verify API и SIM Swap Insight: если замена SIM-карты входит в вашу модель угроз, в этой статье показано, как добавить обнаружение в качестве дополнительного сигнала наряду с Silent Auth.
Улучшите многофакторную аутентификацию с помощью Verify API и SIM Swap Insight: если замена SIM-карты входит в вашу модель угроз, в этой статье показано, как добавить обнаружение в качестве дополнительного сигнала наряду с Silent Auth.
- Беспрепятственная аутентификация на iOS: тихая сетевая верификация с Vonage Verify: практическая реализация для iOS с консолью режима разработчика, которая делает тихий процесс видимым.
Беспрепятственная аутентификация на iOS: тихая сетевая верификация с Vonage Verify: практическая реализация для iOS с консолью режима разработчика, которая делает тихий процесс видимым.
- Представляем Silent Authentication Advanced в Verify API: криптографическая верификация на уровне SIM-карты, которая работает через Wi-Fi и VPN.
Представляем Silent Authentication Advanced в Verify API: криптографическая верификация на уровне SIM-карты, которая работает через Wi-Fi и VPN.
