Credential stuffing — это автоматическая атака, при которой пары логин/пароль, украденные у одного сервиса, проверяются на других сервисах. Она срабатывает, когда люди повторно используют одни и те же данные для входа, поэтому атакуемый сайт мог и не пострадать от исходной утечки. В каталоге OWASP это автоматизированная угроза OAT-008; по-русски термин передают как «подстановка учётных данных» или «набивка учётных данных», а в англоязычных материалах её также называют account checking, credential replay или password list attack.

Ключевые выводы

Credential stuffing воспроизводит уже известные пары учётных данных, а не пытается прежде всего угадать новые пароли.

Один повторно используемый пароль может превратить утечку на малозначимом сайте в доступ к почте, покупкам или финансовым аккаунтам.

Уникальные пароли, менеджеры паролей, MFA и passkey снижают риск на стороне пользователя.

Сервисам нужны многоуровневое обнаружение, блокировка скомпрометированных паролей, ограничение частоты попыток и полезные уведомления безопасности.

Эта атака относится к уровню аккаунтов в руководстве по онлайн-безопасности.

Как работает credential stuffing?

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

OWASP определяет эту угрозу как массовые попытки входа для проверки украденных пар логин/пароль, часто полученных из другого приложения или из открытых данных об утечках.［1］ Целевой сервис мог правильно защитить собственную базу паролей и всё равно получить верные учётные данные, повторно использованные где-то ещё.

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

Чем credential stuffing отличается от перебора, распыления и фишинга?

Атака	Исходные данные	Схема	Основная слабость
Credential stuffing	Украденные пары логин/пароль	Множество известных пар проверяется на разных аккаунтах	Повторное использование учётных данных
Перебор	Множество угадываемых паролей	Много догадок против одного аккаунта	Слабый или предсказуемый пароль
Распыление паролей	Один или несколько популярных паролей	Одни и те же догадки на множестве аккаунтов	Популярные пароли и слабое ограничение частоты попыток
Фишинг	Обманное сообщение или страница	Пользователя вынуждают выдать секрет или одобрить доступ	Отсутствие проверки и социальная инженерия

Руководство OWASP по защите проводит то же различие: при переборе много паролей проверяется на одном аккаунте, при credential stuffing — пары из чужой утечки, а при распылении один слабый пароль пробуют на множестве аккаунтов.［2］ Credential stuffing может использовать данные, изначально собранные фишингом, но автоматическое воспроизведение — отдельный этап.

Почему повторное использование паролей усиливает атаку?

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

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

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

Как защититься от credential stuffing?

Используйте уникальный пароль для каждого аккаунта. Менеджер паролей делает это практичным.
Заменяйте повторяющиеся пароли по приоритету. Начните с основной почты, финансов, облака, платформенных и рабочих аккаунтов.
Включите MFA или используйте passkey. Тогда украденный пароль менее полезен для нового входа.
Реагируйте на достоверные уведомления об утечке. Смените затронутый пароль и все его повторы в других местах.
Проверяйте активность безопасности. Отзывайте неизвестные сеансы, устройства, доступ приложений и способы восстановления.
Не подтверждайте неожиданные запросы MFA. Повторяющиеся запросы могут означать, что у атакующего уже есть пароль.

В руководстве по credential stuffing OWASP называет MFA самой сильной общей защитой и отмечает, что passkey делают более надёжную аутентификацию практичной на современных устройствах. Уникальный пароль всё равно важен, потому что доступность MFA и способы восстановления у сервисов различаются.

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

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

Как сервисам предотвращать атаку?

Одной меры недостаточно. Сервису следует сочетать:

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

NIST требует сверять новые пароли со списком популярных, ожидаемых или скомпрометированных значений и требовать смены пароля при признаках компрометации аутентификатора.［3］ OWASP рекомендует выявлять утёкшие пароли и строить многоуровневую защиту, потому что блокировку по IP или одну CAPTCHA можно обойти либо они наносят неприемлемый вред пользователям.

Почему ограничений и CAPTCHA мало?

Атакующие могут распределять попытки по множеству IP-адресов, снижать темп, имитировать браузеры и повторно использовать пары с высокой вероятностью успеха. Жёсткий глобальный лимит к тому же может заблокировать законных пользователей или стать инструментом отказа в обслуживании.

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

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

Что делать после уведомления?

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

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

Итоги

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

Часто задаваемые вопросы (FAQ)

Это то же самое, что взлом базы паролей?

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

Сложный пароль остановит атаку?

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

Поможет ли менеджер паролей?

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

MFA решает проблему полностью?

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

Устойчивы ли passkey к credential stuffing?

Passkey привязаны к сервису и не создают общей пары с паролем, которую можно использовать повторно. Их внедрение и способы восстановления различаются, поэтому пользователям всё равно стоит проверять сеансы и защищать способы восстановления аккаунта.

Что OWASP говорит о credential stuffing?

В справочнике OWASP по автоматизированным угрозам credential stuffing значится как OAT-008 и отделён от OAT-007 (подбор учётных данных), где значения угадывают, а не воспроизводят украденные пары. Профильная шпаргалка OWASP называет MFA лучшей защитой, а CAPTCHA, меры по IP-адресам, снятие отпечатков и проверку по базам утёкших паролей — дополнительными уровнями.

Зачем атаковать стриминговые или игровые аккаунты?

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

Уведомление означает утечку этого сервиса?

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

Что делать первым после успешного чужого входа?

Отзовите неизвестный сеанс через официальный сервис, смените пароль на уникальный, проверьте настройки восстановления и MFA и защитите все остальные аккаунты, где использовался старый пароль.

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

Источники

OWASP Automated Threats to Web Applications — OAT-008 Credential Stuffing — https://owasp.org/www-project-automated-threats-to-web-applications/assets/oats/EN/OAT-008_Credential_Stuffing
OWASP Cheat Sheet Series — Credential Stuffing Prevention Cheat Sheet — https://cheatsheetseries.owasp.org/cheatsheets/Credential_Stuffing_Prevention_Cheat_Sheet.html
NIST SP 800-63B-4 — Password requirements — https://pages.nist.gov/800-63-4/sp800-63b.html

Sources checked 4 октября 2026 г.

Рекомендуемые статьи:

Что такое credential stuffing?