Как внедрить двухфакторную аутентификацию на своём сайте

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

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

Оценить риски и выбрать область защиты

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

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

Выбрать второй фактор

TOTP-код генерируется приложением или аппаратным токеном и остаётся пригодным короткое время. Он не зависит от сети оператора и обычно удобнее SMS, но пользователю нужно установить приложение и сохранить восстановительные коды. На сервере для администраторов можно отдельно изучить модули PAM: они показывают, как факторы связываются с политиками доступа.

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

Подготовить пользователей и восстановление

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

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

Проверьте также домен и инфраструктуру: изменение DNS-записей, правил перенаправления или сертификата способно перенаправить пользователя на поддельную страницу. В материале о влиянии DNS объясняется роль этих настроек. Уведомления о смене параметров домена стоит получать тому, кто отвечает за безопасность.

Интегрировать проверку в сайт

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

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

Проверить безопасность и качество

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

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

Сопровождать защиту после запуска

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

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

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