Во время входа система сообщает «пользователь не найден» отдельно от «неверный пароль». Какой канал утечки это создаёт?
Такая разница создаёт канал перечисления учётных записей: по ответу системы злоумышленник может определить, зарегистрирован ли конкретный пользователь. Безопаснее возвращать одинаковое внешнее сообщение для неизвестной учётной записи и неверного пароля, а различия фиксировать только во внутренних защищённых журналах.
Системы входа часто разделяли ошибки ради удобства пользователя: отдельно сообщали, что имя не найдено, и отдельно — что пароль неверен. Однако подробные ответы превращают интерфейс аутентификации в средство проверки существования учётных записей.
Обобщённые сообщения стали стандартным защитным приёмом для публичных форм входа, восстановления пароля и регистрации. Исходная проблема — не сама ошибка аутентификации, а раскрытие внутреннего состояния каталога пользователей внешнему наблюдателю.
Злоумышленник отправляет множество известных или случайно сгенерированных идентификаторов и сравнивает ответы. Если для существующего пользователя возвращается один текст, код состояния или структура ответа, а для отсутствующего — другой, каталог можно постепенно восстановить.
Полученный список применяют для целевого подбора паролей, фишинга, атак на восстановление доступа и оценки ценных учётных записей. Даже одинаковый текст не решает проблему, если различаются HTTP-коды, размер ответа, время обработки или наличие дополнительных заголовков.
Внешний контракт должен быть максимально одинаковым: одинаковое общее сообщение, сопоставимые коды состояния, структура и объём ответа. Проверка пароля для неизвестной учётной записи обычно должна имитировать сопоставимую по стоимости работу, например выполнять вычисление стойкого хеша, иначе различие времени также может раскрывать существование пользователя.
Внутри системы ошибки всё равно нужно различать. Защищенный журнал может содержать причину отказа, идентификатор запроса и признаки подозрительной активности, но эти данные не должны возвращаться клиенту.
Одних одинаковых сообщений недостаточно. Нужны ограничение частоты, обнаружение массовых запросов, защита от автоматизации и контроль утечек через восстановление пароля, регистрацию, подсказки поиска и федеративный вход.
Есть компромисс между безопасностью и удобством. Для закрытого административного интерфейса с сильной аутентификацией подробная ошибка может быть приемлема, если раскрытие списка пользователей допустимо по модели угроз. Для публичного входа или восстановления доступа обычно выбирают единообразный ответ.
Публичный портал возвращал разные ответы: для существующего адреса — «неверный пароль», для неизвестного — «пользователь не найден». За короткое время злоумышленник собрал список корпоративных адресов и направил на них фишинговые письма.
Рассматривались три варианта. Простое изменение текста ошибки было быстрым, но не устраняло различия во времени и кодах ответа. Полное скрытие функции входа уменьшало доступность сервиса и не защищало канал восстановления. Выбранное решение использовало единый ответ, сопоставимую обработку обоих случаев, rate limiting и отдельные внутренние события аудита.
После изменения внешний интерфейс перестал надёжно различать существующие и отсутствующие записи, а служба безопасности сохранила возможность выявлять массовые попытки по журналам. При этом защита не гарантирует невозможность перечисления через уже утёкшие данные или побочные каналы других компонентов, поэтому весь жизненный цикл учётной записи нужно проверять целиком.
Нет. Канал может сохраняться через разные HTTP-коды, размеры JSON-ответов, время ответа, заголовки, редиректы или различия в поведении CAPTCHA. Нужно выравнивать все наблюдаемые признаки настолько, насколько это оправдано моделью угроз; абсолютное совпадение времени недостижимо и обычно не требуется.
Это распространённый способ уменьшить временной канал: система выполняет вычисление хеша даже при отсутствии записи. Но стоимость операции нужно ограничивать, иначе массовые запросы сами станут ресурсной атакой. Кроме того, следует учитывать разные алгоритмы хеширования после миграции и не раскрывать результат через побочные метрики.
Форма должна сообщать одинаковый результат вроде «если учётная запись существует, инструкции будут отправлены». Письмо отправляется только существующему адресу, а сервер не должен отличать этот случай внешним ответом. Нужны одноразовые токены с ограниченным сроком действия, защита от массовых запросов и отсутствие токена или иных различающих признаков в URL, логах и аналитике.