Сервис требует второй фактор после успешной проверки пароля. Как это меняет последствия компрометации пароля?
Компрометация пароля перестаёт быть достаточной для входа: злоумышленнику нужен ещё один независимый фактор, например аппаратный ключ или подтверждение на зарегистрированном устройстве. Поэтому многофакторная аутентификация снижает риск захвата учётной записи, но не устраняет его полностью: остаются фишинг, кража активной сессии, компрометация второго фактора и уязвимости восстановления доступа.
Одного пароля недостаточно, потому что его можно подобрать, украсть из базы данных, перехватить через фишинг или повторно использовать после утечки другого сервиса. Многофакторный подход появился как архитектурный способ не считать знание секрета единственным доказательством личности.
Исходная проблема решается разделением доказательств на независимые категории: то, что пользователь знает, имеет или чем является. Компрометация одной категории не должна автоматически давать доступ.
Если пароль является единственным фактором, его утечка обычно позволяет пройти аутентификацию от имени пользователя. Последствия могут включать чтение данных, изменение настроек, выпуск токенов и выполнение операций, доступных этой учётной записи.
При добавлении второго фактора система должна проверить не просто наличие второго значения, а его связь с конкретной учётной записью и текущей попыткой входа. Иначе злоумышленник сможет повторно использовать перехваченное подтверждение или обойти фактор через слабый запасной сценарий.
Важно отличать аутентификацию от авторизации. MFA подтверждает, кто выполняет вход, но не расширяет и не ограничивает права, заданные политикой доступа.
После проверки пароля система переводит вход в промежуточное состояние. Полная аутентификация завершается только после успешной проверки второго фактора; лишь затем выдаются полноценная сессия или токены доступа.
Безопасность зависит от независимости факторов. Код из SMS повышает защиту от простой кражи пароля, но зависит от безопасности телефонного номера и уязвим к атакам на канал доставки. Одноразовые коды из приложения сильнее отделены от пароля, однако могут быть украдены фишингом.
Фишинг-устойчивые методы, такие как аппаратные ключи с криптографической привязкой к домену, лучше защищают от поддельного сайта: подтверждение не предназначено для другого домена. При этом нужно безопасно связывать ключ с учётной записью, поддерживать отзыв и регистрацию резервных ключей.
Нельзя считать MFA эффективным, если восстановление доступа требует только пароля, контрольного вопроса или обращения в поддержку без сопоставимой проверки личности. Слабый recovery-процесс становится обходным путём вокруг сильного входа.
После успешного входа необходимо защищать выданную сессию: использовать безопасные атрибуты cookie, ограничивать срок жизни чувствительных сессий и повторно запрашивать фактор для критичных операций. MFA не спасает от кражи уже созданного токена, если сервер принимает этот токен без дополнительной проверки.
Корпоративный портал использует пароль и одноразовый код из приложения. После утечки паролей злоумышленники смогли начать вход, но не смогли завершить его без кодов. Это существенно сократило масштаб захвата учётных записей.
Рассматривались три варианта. SMS был проще для пользователей, но зависел от телефонного номера; одноразовые коды из приложения не требовали сети, но оставались уязвимыми к убедительному фишингу; аппаратные ключи давали лучшую защиту от поддельных сайтов, но требовали закупки, регистрации резервных ключей и процесса восстановления.
Для администраторов и доступа к критичным системам выбрали аппаратные ключи, а для менее чувствительных сценариев оставили приложение с одноразовыми кодами. Восстановление сделали двухэтапным: резервный ключ или подтверждение через заранее зарегистрированный процесс с ручной проверкой. Такой компромисс повысил защиту критичных учётных записей, не сделав MFA недоступной для остальных пользователей.
Нет. Пользователь может сообщить код фишинговому сайту, а злоумышленник немедленно передаст его настоящему сервису. SMS также зависит от безопасности телефонного номера и сети оператора, поэтому его обычно рассматривают как более слабый фактор, чем фишинг-устойчивый криптографический ключ.
MFA обычно проверяется при создании сессии, а последующие запросы подтверждаются выданным cookie или токеном. Если злоумышленник получил этот артефакт, сервер может считать запрос уже аутентифицированным. Снижают риск короткий срок жизни токенов, их отзыв, защита от кражи в браузере и повторная проверка фактора перед особо чувствительными действиями.
Безопасный вариант — заранее предусмотреть несколько независимых способов восстановления: резервный аппаратный ключ, заранее выданные одноразовые коды или строго контролируемую ручную процедуру. Простое отключение MFA по одному паролю создаёт обход, делающий исходную защиту бессмысленной. При этом резервные способы должны защищаться не слабее основного сценария и подлежать отзыву после использования или компрометации.