После взлома провайдера аутентификации: сброс паролей затронутых пользователей, восстановление сессий и проверка паролей по базам утечек

Цель

Сведения актуальны на 25 октября 2026 года. Вернуть затронутым пользователям контроль после взлома провайдера аутентификации и снизить риски повторного использования паролей. Заново проверьте охват раскрытия у провайдера, документацию по восстановлению и контракт Pwned Passwords API. Базовым ориентиром служит NIST SP 800-63B-4, окончательная редакция которого опубликована 31 июля 2025 года; это не процедура установки исправлений ПО. Сведения о публикации.

Предварительные условия

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

Шаги

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

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

3. Отслеживайте подстановку украденных учётных данных. OWASP определяет credential stuffing как повторное использование пар «имя пользователя — пароль», украденных в другом месте. Изучайте результаты аутентификации по учётным записям и источникам, включая случаи успешной проверки пароля с последующей неудачей многофакторной проверки. Отслеживайте трафик, обнаруженный и заблокированный каждой мерой защиты, и расследуйте подозрительные успешные входы. Применяйте многофакторную аутентификацию и многоуровневую защиту; одной блокировки IP-адресов недостаточно. Защита от credential stuffing.

4. Проверяйте новые пароли с сохранением конфиденциальности. NIST требует сверять выбираемые пароли с распространёнными, предсказуемыми или скомпрометированными значениями. Для поиска в Pwned Passwords локально вычислите хеш SHA-1 от байтов введённого пароля в UTF-8, применив ту же нормализацию, что и компонент проверки пароля. Отправьте только первые пять шестнадцатеричных символов хеша в GET https://api.pwnedpasswords.com/range/{prefix}. Передайте Add-Padding: true; локально сравните возвращённые суффиксы с оставшейся частью хеша. Совпадающий суффикс с положительным счётчиком означает наличие пароля в наборе данных; отбросьте записи заполнения с нулевым счётчиком. Отклоните найденный пароль, объясните причину и потребуйте выбрать другой. Ключ API не требуется. Никогда не передавайте полный пароль, полный хеш или идентификатор учётной записи. Выполняйте запрос только после завершения ввода, а не после каждого нажатия клавиши. Range API, требования NIST к проверке паролей.

5. Разделяйте проверку и хранение. SHA-1 здесь используется для поиска, а не для хранения паролей. Сохраняйте хеширование паролей с солью и настраиваемой вычислительной стоимостью, как предписывает NIST. Выполняйте проверку, пока новый пароль доступен в штатном защищённом процессе смены; не собирайте существующие пароли для пакетного аудита. База утечек дополняет проверки на распространённые варианты и варианты, предсказуемые в данном контексте. Требования NIST.

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

Ожидаемый результат

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

Ограничения и основание проверки

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