Пароль, СМС или passkey: как выбирают метод входа на сайт и чем платят за каждый

Сразу и коротко

Идеального метода входа не существует. Есть компромисс между тремя вещами: насколько трудно взломать, насколько трудно пользоваться и насколько трудно поддерживать. Улучшаете одно — почти всегда проседает другое.

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

Если совсем сжать:

• Пароль без второго фактора — приемлемо только там, где взлом аккаунта ничем не грозит.
• Второй фактор в приложении (TOTP) — лучшее соотношение «защита / стоимость» для большинства продуктов.
• СМС — не защита, а барьер от массовых автоматических регистраций. Против прицельной атаки на конкретный аккаунт не работает.
• Passkey / WebAuthn — единственный массовый метод, который в принципе нельзя отдать фишинговому сайту.
• Корпоративный SSO — не про безопасность входа, а про управляемость: доступ выдаётся и, что важнее, отзывается из одной точки, а не вручную в каждой системе по отдельности.
• Самое слабое место любой схемы — не вход, а восстановление доступа. Ломают почти всегда там.

Частые проблемы, связанные со входом

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

Последствия проявляются позже и выглядят буднично — это не про громкий взлом, а про повседневные мелочи, которые накапливаются:

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

Ни одну из этих бед не лечит выбор «более безопасного» метода. Они лечатся раньше — в тот момент, когда вы понимаете, что именно выбираете и чем за это заплатите.

Что значит «двухфакторная» авторизация? Бывает «однофакторная»?

В быту говорят «двухфакторная авторизация», и все понимают, о чём речь. Но, на самом деле, это аутентификация — подтверждение, кто ты. Авторизация — это уже про права (что тебе можно после входа). «Факторы» относятся ко входу, то есть к аутентификации. Так что технически правильно — «двухфакторная аутентификация». В обиходе прижилось «авторизация», потому что короче и на слуху, но в тексте, который сам объясняет разницу этих слов, лучше писать точно.

Что такое «фактор»

Фактор — это категория доказательства того, что ты — это ты. Их всего три типа:

• Знание — то, что ты знаешь: пароль, PIN, ответ на секретный вопрос.
• Владение — то, что у тебя есть: телефон (куда придёт код), приложение-аутентификатор, физический ключ.
• Свойство — то, чем ты являешься: отпечаток, лицо, голос.

Количество факторов — это сколько разных категорий ты предъявляешь при входе.

Однофакторная — да, бывает, и это большинство входов

Однофакторная (1FA) — вход по одному фактору. Классика — просто логин и пароль. Один фактor, категория «знание». Всё, что вы вводите только пароль и попадаете внутрь, — это однофакторная аутентификация.

Двухфакторная (2FA) — два фактора из разных категорий. Пароль (знание) + код из приложения (владение). Именно «из разных» — ключевое условие.

Многофакторная (MFA) — два и более. 2FA — это частный случай MFA.

Методы входа: чем подтверждают личность

Метод	Стойкость к фишингу	Удобство для пользователя	Цена внедрения и владения	Где уместен
Пароль	Низкая	Высокое	Низкая	Аккаунты, где взлом ничем не грозит
Пароль + TOTP (код из приложения)	Средняя	Среднее	Низкая	Дефолт для большинства продуктов с ценным аккаунтом
СМС-код	Низкая	Высокое	Средняя (плата за сообщение)	Подтверждение регистрации, антибот-барьер
Звонок на выданный номер	Низкая	Высокое	Средняя (аренда пула номеров)	Удобное подтверждение номера, антифрод-сигнал
Ссылка/код на почту	Низкая	Низкое (переход в почту)	Низкая	Продукты без паролей, редкий вход
Вход через провайдера (OAuth/OIDC)	Средняя	Высокое	Средняя	B2C, быстрая регистрация в один тап
Корпоративный SSO	Средняя	Высокое	Высокая	B2B, требование службы безопасности заказчика
Passkey / WebAuthn	Высокая	Высокое	Средняя	Основной метод будущего, нужен резервный путь
Аппаратный ключ	Высокая	Среднее	Высокая (железо + процедуры)	Администраторы, доступ в боевую систему

Логин и пароль

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

Беда пароля не в том, что его подберут. Если пароли хранятся правильно — не в открытом виде, а в виде необратимого «отпечатка», который вдобавок намеренно долго вычисляется (для этого есть проверенные алгоритмы вроде Argon2id или bcrypt), — перебор становится экономически бессмысленным: считать придётся слишком долго и дорого. Настоящая беда в другом: пароли переиспользуют. У человека с одним паролем на тридцати сайтах ваш аккаунт умирает в тот момент, когда пароль утекает с любого из этих тридцати. Атаку называют credential stuffing («набивание учёток»): стоит она копейки и идёт фоном постоянно — боты просто прогоняют по вашей форме входа готовые списки украденных пар «почта — пароль».

Что реально помогает: сверять вводимый пароль с базами известных утечек, ограничивать попытки по IP и по аккаунту, требовать длину вместо «обязательной заглавной и спецсимвола». А вот принудительная смена пароля каждые 90 дней только вредит — люди начинают писать Лето2026!, потом Осень2026!, и вы сами понимаете, чем это кончается.

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

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

Пароль плюс одноразовый код из приложения (TOTP)

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

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

Плюсы: дёшево, автономно, никакой зависимости от оператора связи, реально останавливает credential stuffing.

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

Код по СМС или голосовым звонком

Самый популярный метод входа — и самый переоценённый.

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

Это не значит «никогда». СМС отлично отсекает автоматический мусор при регистрации и выручает там, где у пользователя вообще ничего нет, кроме кнопочного телефона. Но считать его защитой аккаунта, внутри которого лежат деньги, — самообман.

Плюсы: работает у всех без установки приложений, привычен, попутно подтверждает контакт.

Минусы: SIM-swap, цена за каждое сообщение, сбои доставки, зависимость от третьей стороны и — самое коварное — ложное чувство защищённости.

Звонок от пользователя на выданный номер

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

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

Экономика тоже за неё: неотвеченный вызов пользователю обычно не тарифицируется, а бизнес платит не за каждое подтверждение, а за аренду пула номеров и подключение. На больших объёмах разрыв с СМС весомый.

Теперь то, за что приходится платить.

Фактор всё тот же — номер телефона. Перевыпуск SIM ломает схему ровно так же, как ломает СМС. Только атакующему теперь достаточно один раз позвонить.

Всё держится на определителе номера, а он ничем не подписан. Внутри сети оператора подмена, как правило, отфильтрована, но транзитные и международные маршруты — отдельный разговор, и это ваш риск, а не оператора.

Схема подтверждает номер, но не подтверждает сайт. Это главное и наименее очевидное. Фишинговая страница может запустить вход у вас, получить номер и показать его жертве как свой — человек позвонит, и подтверждённой окажется сессия атакующего. Устойчивости к фишингу здесь нет по конструкции, как и у кодов: низкий порог для пользователя означает низкий порог и для атаки.

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

Пул номеров и состояние гонки. Номер выдаётся на короткое время и должен быть уникален именно в этот момент, иначе два одновременных входа перепутаются между собой. Привязка всегда по паре «на какой номер позвонили — с какого номера», срок жизни в минутах, повторная выдача номера с задержкой. Размер пула считается по пиковой одновременности, а не по суточному объёму.

Телеком-детали, которые всплывают только на проде. Часть операторов не доводит сигнализацию до платформы, если вызов сброшен слишком рано, и подтверждение теряется. Нужен договор с оператором или агрегатором, корректная передача номера вызывающего и продуманное поведение в случае «человек дозвонился, а мы этого не увидели».

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

Ссылка или код на почту вместо пароля

Пользователь вводит адрес, получает письмо, жмёт — вошёл. Пароля нет в принципе.

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

Плюсы: в вашей базе нечего красть, нет тикетов про забытый пароль, регистрация простая.

Минусы: вход занимает 30–60 секунд и требует прыжка в другое приложение — на мобильных это ощутимая потеря конверсии. Письма уходят в спам и в корпоративные фильтры. Ссылку можно переслать. А если ящик угнали — угнали всё разом.

Вход через внешнего провайдера

Кнопка «войти через…». За ней технически стоит связка из двух стандартов: OAuth 2.0 отвечает за доступ, а надстройка OpenID Connect (OIDC) — за саму идентификацию пользователя. И здесь есть важная деталь: сам по себе OAuth 2.0 — это не про «кто ты», а про «что тебе разрешено взять». Если строить на нём вход без слоя OIDC, возникает целый класс известных уязвимостей — грубо говоря, пропуск, выписанный для одного приложения, принимает другое и пускает не того человека.

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

Минусы: вы отдаёте контроль над доступом к собственному продукту. Провайдер заблокировал аккаунт — пользователь потерял и ваш заодно. Поменялись условия API — вы переделываете вход. И отдельная головная боль: люди не помнят, какой кнопкой регистрировались, заводят второй аккаунт на тот же адрес, а связывание учёток приходится продумывать заранее, а не после первых жалоб.

Корпоративный единый вход (SSO)

Внутри организации — вход через собственный каталог или провайдера идентификации, по OIDC или SAML. Для B2B-продукта это сплошь и рядом не «фича», а условие сделки: без SSO вас просто не пропустит служба информационной безопасности заказчика.

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

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

Минусы: внедрять заметно сложнее, особенно на SAML с его XML и подписями. Провайдер становится единой точкой отказа: он лёг — не работает никто. А каждый корпоративный клиент настроен чуть по-своему, и поддержка этого зоопарка со временем вырастает в отдельный продукт.

Passkey и WebAuthn

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

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

Плюсы: устойчивость к фишингу, вход одним жестом, никаких секретов на сервере.

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

Аппаратные ключи и сертификаты

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

Биометрия

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

Машина к машине

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

Как выбрать метод: три главных вопроса

Таблица выше показывает расклад по каждому методу. Но если решать надо здесь и сейчас, выбор быстрее сужают три вопроса.

Чем обернётся один взломанный аккаунт?

Ничем — хватит пароля с защитой от подбора. Потерей денег или персональных данных — второй фактор обязателен. Доступом в боевую систему — только устойчивый к фишингу метод, без вариантов.

Кто ваши пользователи?

Массовый потребитель сбежит от сложного входа. Сотрудник обязан пройти любой. Корпоративный клиент придёт со своими требованиями и своим провайдером — и вам придётся под них лечь.

Что вы готовы поддерживать?

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

FAQ

Достаточно ли одного пароля, если он длинный и сложный?

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

Можно ли считать СМС нормальным вторым фактором?

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

Passkey уже можно использовать как единственный метод входа?

Технически да, практически — пока нет. Останутся пользователи со старыми устройствами, корпоративными политиками и потерянными телефонами, и им нужен резервный путь. Реалистичный план на сегодня: passkey как основной метод и один продуманный резервный, а не полный отказ от остальных.

Чем отличается SSO от кнопки «войти через провайдера»?

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

Что выбрать: серверные сессии или JWT?

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

| 2Dit Tech