От паролей к MFA

Почему пароли не масштабируются

Пароль — это общий секрет: его знает пользователь и знает твой сервер. Эта симметрия и есть вся проблема. Пользователь переиспользует секрет на десятках сайтов, поэтому его безопасность не выше, чем у худшего сайта, на котором он его когда-либо вводил, — а тот сайт тебе не подконтролен. Исследования больших корпусов утечек дают переиспользование паролей выше 50% пользователей; один этот факт и есть причина, по которой дамп с никак не связанного сервиса становится атакой на тебя.

Три сбоя усиливают друг друга:

• Переиспользование → credential stuffing. Атакующие берут миллиарды утёкших пар email:пароль (одна только «Collection #1» содержала ~773 млн уникальных email) и проигрывают их по твоему логину через сменяющиеся прокси. Доля успеха в 0,1–2% звучит ничтожно, пока не умножишь на миллионы попыток: 0,5% попаданий на 10 млн попыток — это 50 000 скомпрометированных аккаунтов, а в логах просто много валидных входов.
• Подбор → brute force и спрей. Против одного аккаунта помогают rate-лимиты и блокировки. Password spraying их обходит: пробуешь один распространённый пароль (Winter2024!) по десяти тысячам аккаунтов, так что ни один аккаунт не триггерит блокировку. Счётчики на аккаунт не срабатывают; нужна детекция по источнику и по паттерну учёток.
• Ошибки хранения → офлайн-взлом. Если твоё хранилище паролей утекло, у атакующего пошёл отсчёт. Открытый текст или несолёный MD5/SHA-1 — и вся таблица вскрывается за часы на ширпотребной GPU-ферме, делающей десятки миллиардов попыток в секунду. Корректно выбранный медленный, солёный, memory-hard хеш (Argon2id, scrypt или bcrypt) — вот что покупает тебе время: соль убивает заранее посчитанные rainbow-таблицы и заставляет работать по каждому аккаунту, а намеренная медлительность ограничивает скорость перебора.

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

Чем помогает MFA — и как его обходят

Многофакторная аутентификация требует свидетельства из более чем одной категории: что-то, что ты знаешь (пароль), что-то, что у тебя есть (телефон, ключ безопасности), что-то, чем ты являешься (отпечаток). Суть не в том, что какой-то один фактор силён; суть в том, что атакующему теперь нужно скомпрометировать две несвязанные вещи разом. Против массового credential stuffing это разгром: у бота есть пароль, но нет второго фактора, и автоматический угон умирает. Microsoft и Google оба сообщали, что MFA блокирует заметно больше 99% автоматических попыток компрометации. Это число реально — и здесь же люди перестают думать, что и есть опасная часть.

MFA не бинарно. Факторы образуют лестницу силы, и целевой атакующий (в отличие от массового бота) рутинно ломает слабые ступени:

• Одноразовые коды по SMS одновременно фишабельны и перехватываемы. SIM-swap — социнженерия оператора, чтобы перенести номер жертвы на SIM атакующего, — доставляет код прямо ему. SMS лучше, чем ничего, и куда лучше против ботов, но NIST годами не рекомендует его как основной фактор.
• TOTP-приложения (6-значный код, меняющийся каждые 30 секунд, RFC 6238) убирают оператора из цепочки — секрет живёт на устройстве. Но код по-прежнему то, что пользователь может прочитать и ввести, а значит, его можно обманом заставить ввести код на поддельном сайте.
• Push-уведомления добавляют тап, но вносят MFA-усталость: засыпать жертву запросами в 3 ночи, пока она не нажмёт «подтвердить», лишь бы это прекратилось. Так взломали Uber и других. Number-matching (в запросе показывается число, которое надо ввести) притупляет приём, но не убирает человека из цепочки.

Обход, связывающий слабые ступени воедино, — это фишинг-прокси реального времени (Evilginx, Modlishka и им подобные). Жертва попадает на пиксель-в-пиксель прокси твоего логина. Она вводит пароль — прокси ретранслирует его на настоящий сайт. Настоящий сайт просит TOTP-код — прокси ретранслирует запрос, жертва вводит код, прокси ретранслирует и его. Настоящий сайт выдаёт cookie сессии, и прокси крадёт её. У атакующего теперь аутентифицированная сессия, и ни пароль, ни код ему больше не нужны. Любой фактор, который пользователь вводит, проигрываем через этого «человека посередине» — вот вся причина, по которой «phishing-resistant» это отдельное, более трудное свойство.

Phishing-resistant факторы

Фактор устойчив к фишингу, когда кража того, что ввёл пользователь, не даёт атакующему ничего — потому что вводить нечего. Механизм — криптография на открытых ключах, привязанная к origin, стандартизированная как WebAuthn / FIDO2 и доехавшая до пользователей как passkey и аппаратные ключи безопасности.

Вот значимый механизм. При регистрации аутентификатор (YubiKey или защищённый элемент в телефоне) генерирует новую пару ключей, привязанную к твоему точному origin, https://yourbank.com. Приватный ключ никогда не покидает устройство; сервер хранит только публичный. При входе сервер шлёт случайный challenge; аутентификатор подписывает его приватным ключом, а браузер включает настоящий origin в то, что подписывается. Из этого единственного решения выпадают два следствия:

1. Нет общего секрета, который можно сфишить. Пользователь не вводит ничего, что атакующий мог бы проиграть. Подпись для одного challenge бесполезна для следующего.
2. Привязка к origin убивает прокси. Если жертва на yourbank.evil.com, браузер подписывает этот origin — и твой сервер, ожидающий yourbank.com, отвергает подпись. Ретранслятор Evilginx рушится, потому что учётка отказывается работать где-либо, кроме подлинного сайта. Этого свойства лишены SMS, TOTP и push.

Зрелый вывод — тиражируемый по уровню угрозы. Любой MFA крушит проблему массовых ботов, поэтому самая дешёвая крупная победа — включить какой-нибудь второй фактор всем. Но для аккаунтов, которые важны — админы, финансы, любой с доступом к проду, — вводимых факторов мало, потому что это ровно те аккаунты, которые живой атакующий будет фишить в реальном времени. Там планка — phishing-resistant WebAuthn. И не дай MFA стать единой точкой отказа: слабое восстановление доступа («потерял телефон, пришлите код на старый номер») — та задняя дверь, что тихо понижает твой сильнейший фактор до слабейшего.