2FA и пароли: как защитить аккаунты пользователей вашего сервиса

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

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

Почему это ваша зона ответственности, а не пользователя

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

Как на самом деле взламывают пользовательские аккаунты

• Подстановка утёкших паролей. Люди повторяют один пароль на десятке сайтов. Когда утекает база какого-нибудь форума, пары «почта — пароль» прогоняют скриптом по сотням сервисов, включая ваш. Атакующему не нужно ничего знать о вашем продукте.
• Перебор. Если форма входа не ограничивает число попыток, простые пароли подбираются за часы. Особенно уязвимы короткие цифровые ПИН-коды и пароли «как у всех».
• Фишинг. Клиенту приходит письмо или сообщение «от вашего имени» со ссылкой на поддельную страницу входа. Пароль вводится добровольно.
• Слабое восстановление доступа. Ссылка сброса, которая живёт неделю, или служба поддержки, которая меняет почту в аккаунте по звонку «я забыл пароль», — короткий путь в чужой кабинет без всякого пароля.
• Захват почты пользователя. Если почта клиента взломана, через «забыли пароль» взламывается и всё, что к ней привязано, включая ваш сервис.
• Перехват сессии. Украденная кука сессии даёт доступ без пароля и без второго фактора — поэтому защищать нужно не только вход, но и то, что происходит после него.

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

Политика паролей: что утвердить

Старые правила — «восемь символов, заглавная, цифра, спецсимвол, смена раз в три месяца» — дают предсказуемый результат: Masha2024!, потом Masha2025!. Современные рекомендации, в том числе руководство NIST SP 800-63B, исходят из другой логики: длина важнее набора символов, а главная проверка — не «сложный ли пароль», а «не засвечен ли он уже в утечках». Для пользовательских аккаунтов разумный набор правил выглядит так:

• Минимальная длина — не меньше 8 символов, а для сервисов с деньгами и документами — от 12. Максимальную длину не ограничивайте искусственно короткой: парольные фразы из нескольких слов должны проходить.
• Никаких обязательных «заглавная плюс спецсимвол». Вместо этого — проверка по списку самых распространённых и уже утёкших паролей с понятным сообщением: «этот пароль слишком часто встречается в утечках, выберите другой».
• Никакой принудительной смены по календарю. Смена — только при подозрении на компрометацию, и тогда она обязательна.
• Разрешите вставку пароля из буфера и автозаполнение. Запрет вставки не повышает безопасность, а мешает менеджерам паролей — лучшему, что может сделать пользователь.
• Кнопка «показать пароль» и индикатор, который объясняет, а не ругает.
• Пароль нельзя установить равным логину, почте или названию сервиса.

Что потребовать от разработчиков по хранению и входу

Владельцу не нужно разбираться в криптографии, но нужно знать, какие вопросы задать команде или подрядчику. Ответы на них должны быть короткими и уверенными; если вместо ответа начинается «ну, вроде бы…», это повод для аудита.

• Пароли хранятся только в виде хеша медленным алгоритмом, предназначенным для паролей (argon2id, bcrypt, scrypt), с уникальной солью. Не MD5, не SHA-1, не «зашифровано ключом, который лежит рядом».
• Пароль не попадает в логи, письма, аналитику и ответы службы поддержки. Ни один сотрудник не может его посмотреть — только сбросить.
• Сравнение секретов и токенов выполняется функциями, устойчивыми к атакам по времени.
• Форма входа ограничивает частоту попыток — и по аккаунту, и по IP-адресу. После нескольких неудач растёт задержка или появляется проверка «я не робот».
• Аккаунт не блокируется намертво после N ошибок: иначе любой может заблокировать чужой кабинет, просто введя неверный пароль. Задержка и дополнительная проверка лучше полной блокировки.
• Ответ на ошибку входа одинаковый: «неверная почта или пароль». По тексту ошибки нельзя понять, зарегистрирован ли такой человек.
• При входе с нового устройства пользователь получает уведомление и может одним нажатием завершить чужую сессию.

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

2FA для клиентов: обязательно или по желанию

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

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

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

Какой второй фактор предложить клиентам? Варианты — от привычного к самому надёжному:

• Код по SMS — привычен всем, но уязвим к перевыпуску SIM-карты и перехвату, а каждое сообщение стоит вам денег. Годится как запасной вариант и для массовой аудитории, но не для доступа к деньгам и админке.
• Код на почту — бесплатен, но работает только если почта клиента защищена лучше, чем ваш сервис. Часто это не так.
• Приложение-аутентификатор с одноразовыми кодами по стандарту TOTP — надёжный и бесплатный вариант: общий секрет передаётся один раз через QR-код, дальше коды генерируются офлайн каждые 30 секунд. Для пользователя — две минуты на настройку.
• Ключи доступа (passkeys) и аппаратные ключи на основе стандарта WebAuthn — самый устойчивый к фишингу способ: браузер проверяет адрес сайта и не отдаст подтверждение поддельной странице. Для пользователя часто ещё и удобнее пароля — вход по отпечатку или лицу на своём устройстве.
• Резервные одноразовые коды — не самостоятельный способ, а обязательное дополнение к любому из перечисленных.

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

Восстановление доступа и сессии

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

• Токен сброса — одноразовый, случайный, с коротким сроком жизни (час, а не неделя). В базе хранится его хеш, а не сам токен.
• Ответ на запрос сброса одинаковый для существующей и несуществующей почты.
• После смены пароля все активные сессии завершаются, а пользователь получает уведомление на почту и, если есть, в приложение.
• Сброс пароля не отключает второй фактор. Если 2FA включена, после сброса её всё равно нужно пройти.
• Потеря второго фактора — отдельная процедура: резервный код, а если его нет — проверка личности по заранее описанному регламенту с задержкой и уведомлением на все известные контакты. Не «поддержка отключила по звонку».
• Смена почты или телефона в аккаунте подтверждается и со старого, и с нового адреса, а на старый уходит уведомление с возможностью отменить изменение.

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

Условный пример: кабинет с бонусным счётом

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

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

Ни одна мера по отдельности не идеальна, но каждая обрывает свою часть цепочки. Именно так и стоит смотреть на политику: не «включили 2FA — защищены», а «на каком шаге остановится атакующий».

Как не убить конверсию

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

Проверьте свой сервис за 15 минут

• Попробуйте ввести неверный пароль 20 раз подряд — появляется ли задержка или проверка?
• Отличается ли текст ошибки для зарегистрированной и незарегистрированной почты?
• Сколько живёт ссылка сброса пароля и можно ли использовать её дважды?
• Приходит ли уведомление о смене пароля и о входе с нового устройства?
• Есть ли у клиентов возможность включить второй фактор, а у администраторов — обязательность?
• Требуется ли подтверждение при смене почты, телефона и реквизитов?
• Можете ли вы получить от разработчиков письменный ответ, каким алгоритмом хешируются пароли?

Вывод

Защита пользовательских аккаунтов — это не одна галочка «включить 2FA», а набор правил для входа, восстановления, сессий и чувствительных действий. Начните с того, что проверяется за час: ограничение попыток, одинаковые ошибки, короткоживущие токены сброса и уведомления. Затем решите, где второй фактор обязателен, а где достаточно повторного подтверждения действий. Если хотите, чтобы этот список проверил кто-то со стороны, — посмотрите, что входит в наш аудит безопасности, или опишите ваш сервис, и мы подскажем, с чего начать.