Вход без СМС: passkeys, TOTP, e-mail и резервные коды без мифов

Если нужен короткий ответ, то картина такая. Для большинства людей лучший основной вариант сегодня дают passkeys, то есть ключи доступа. Для запасного входа лучше всего держать TOTP в приложении-аутентификаторе. Вход по почте годится не везде и чаще подходит для менее ценных сервисов, где важнее простота, чем максимальная стойкость. Резервные коды нужны почти всегда, но как аварийный инструмент, а не как обычный способ входа.

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

Что реально сильнее СМС, а что просто выглядит современно

Passkeys, лучший кандидат на роль «входа без СМС»

У ключей доступа сейчас самое удачное сочетание безопасности и удобства. Пользователь не вводит секрет руками, сайт получает подтверждение через криптографическую пару ключей, а сам ключ привязывается к конкретному домену. За счёт такой схемы passkeys устойчивы к классическому фишингу, где жертву уводят на поддельную страницу и просят ввести пароль или одноразовый код. Базовое описание механики есть у FIDO, а в корпоративных рекомендациях Microsoft passkeys прямо описываются как фишинг-устойчивые учётные данные.

Но и здесь нет сказки. У passkeys есть две большие ветки. Первая, синхронизируемые ключи, живут в экосистеме Apple, Google, менеджера паролей или другого поставщика. Такой вариант очень удобен, потому что новый телефон или ноутбук часто подхватывает ключи без боли. Вторая, привязанные к устройству ключи, не покидают конкретное устройство или аппаратный токен. Такой вариант жёстче по защите, но с ним чаще труднее пережить потерю железки.

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

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

TOTP, рабочая лошадка, но не броня

TOTP хорош не потому, что идеален, а потому, что почти везде поддерживается. Алгоритм простой: у сервиса и у приложения-аутентификатора есть общий секрет, а код пересчитывается по времени, обычно каждые 30 секунд. Краткий технический разбор есть на SecurityLab. В реальной жизни TOTP остаётся самым универсальным запасным вариантом, когда passkeys сервис ещё не умеет или реализовал криво.

Слабое место TOTP давно известно. Пользователь сам видит код и сам вводит код, значит код можно выманить через фишинговую страницу и использовать сразу, пока таймер не истёк. NIST прямо пишет, что OTP-аутентификация не является фишинг-устойчивой. Поэтому TOTP не стоит романтизировать. TOTP лучше СМС, но TOTP не делает человека неуязвимым.

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

Из-за этого TOTP лучше воспринимать как хороший запасной этаж, а не как конечную вершину. Если сервис поддерживает и passkeys, и TOTP, для большинства пользователей логичнее включить оба метода и использовать TOTP как резерв, а не как основной вход.

E-mail, удобный путь, который часто притворяется вторым фактором

Вход по почте бывает в двух вариантах. Первый, magic link или код на e-mail как основной способ входа. Второй, письмо как дополнительное подтверждение после пароля. В обоих случаях безопасность аккаунта сводится к безопасности почтового ящика. Если ящик плохо защищён, весь «вход без СМС» превращается в красивую обложку.

На практике почта подходит для сервисов с низкой ценностью аккаунта: форумы, магазины, разовые регистрации, некоторые SaaS с короткими сессиями. Для основной почты, облака, криптокошелька, корпоративных систем или панели администратора такой путь уже слишком мягкий. У NIST позиция жёсткая: e-mail вообще не должен использоваться как out-of-band аутентификация, а в OWASP отдельно подчёркивается, что почта считается фактором «что у вас есть» только если сам почтовый ящик уже защищён многофакторно.

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

Резервные коды, скучный инструмент, который спасает чаще всего

Почти все любят обсуждать биометрию, QR-коды и беспарольное будущее, но реальную жизнь чаще спасают резервные коды. Причина проста: телефон теряют, разбивают, топят, меняют, забывают дома, разряжают в неудобный момент. Резервный код не требует сети, SIM-карты, исправной камеры и живой батареи. Резервный код просто даёт войти один раз и заново собрать защиту.

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

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

Что ломает любую схему, даже если на бумаге всё красиво

Первое слабое место, фишинг. Passkeys здесь сильнее остальных, потому что пользователь не вручную передаёт сайту секрет. TOTP, e-mail-коды и резервные коды пользователь передаёт сам, а значит их можно выманить в реальном времени. Второе слабое место, восстановление после потери устройства. Слишком жёсткая схема без аварийного пути превращается в ловушку для владельца. Слишком мягкая схема превращается в подарок для захватчика аккаунта. Третье слабое место, концентрация всего в одном месте. Один и тот же телефон, одна и та же сессия почты, один и тот же менеджер, один и тот же облачный аккаунт, и один инцидент пробивает сразу весь контур.

Отдельно стоит помнить про номер телефона. СМС уже давно не выглядит хорошим дефолтом, и дело не только в удобстве. NIST относит PSTN-подтверждение к ограниченным методам и отдельно советует учитывать SIM swap, перенос номера и другую аномальную активность. Поэтому идея «уберём пароль, оставим СМС как запасной путь» выглядит устаревшей почти во всех серьёзных сценариях.

Какая схема реально работает у обычного человека

Для личных аккаунтов, где нужна нормальная защита без фанатизма, рабочая схема выглядит так:

• для сервисов, которые умеют passkeys, включить passkeys как основной вход;
• для тех же сервисов, если доступен TOTP, включить TOTP как запасной способ;
• скачать или распечатать резервные коды и хранить отдельно от телефона;
• почтовый ящик, на который завязано восстановление, защитить сильнее всех остальных аккаунтов;
• раз в несколько месяцев проверять, какие устройства и способы входа привязаны к аккаунту.

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

Где советы выше не сработают или сработают не полностью

Если сам сервис плохо реализовал аутентификацию, пользователь мало что исправит. Бывает, что продукт красиво показывает поддержку passkeys, а потом оставляет старый вход по паролю без нормального контроля устройств. Бывает, что TOTP включён, но API или мобильное приложение обходят вторую проверку. Бывает, что резервные коды можно бесконечно перебирать или система не уведомляет об использовании аварийного входа. В таких случаях проблема не в выбранном методе, а в кривой реализации сервиса.

Есть и бытовой предел. Если человеку нужен вход с десятков чужих машин, старых браузеров и корпоративных терминалов, одни методы окажутся удобнее на бумаге, чем в реальной среде. TOTP до сих пор выигрывает у passkeys именно совместимостью. Поэтому полностью списывать TOTP рано, даже если с точки зрения безопасности passkeys смотрятся убедительнее.

Практический вывод

Убирать СМС есть смысл, но менять СМС на первый попавшийся модный вариант не стоит. Лучший основной путь для большинства аккаунтов сегодня дают passkeys. Лучший универсальный резерв остаётся за TOTP. Почта годится как удобный, но более слабый путь для низкорисковых сервисов и как часть восстановления, если сам ящик защищён сильнее всех остальных аккаунтов. Резервные коды скучны, зато реально спасают, когда телефон недоступен и красивый беспарольный мир внезапно заканчивается.

Если свести всё к одному правилу, правило будет таким: стройте не «самый современный вход», а схему, где основной метод силён, запасной метод совместим, а аварийный путь не пробивает весь контур безопасности.