User enumeration
как атакующие узнают, кто у вас в системе (и как с этим жить)

Автор: Dungleton Security
Для кого: все, кто хоть раз получал письмо «восстановите пароль» и думал
Зачем атакующему перечислять пользователей

User enumeration - Это разведка.

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

Если логин реальный - с ним уже можно что-то делать:

• подобрать пароль (или проверить утёкший),
  
• сделать правдоподобный фишинг,
  
• использовать как якорь для дальнейших атак.

Если логин выдуманный — он бесполезен.
Поэтому первая задача — отделить реальные аккаунты от мусора.

Мы в Dungleton регулярно видим, как это делают на практике, чаще всего применяя к нам(
Если атакующий знает несколько реальных имён (а они почти всегда где-то есть — сайт, LinkedIn, конференции), дальше всё механически: берём список имён, прогоняем через форму регистрации, отмечаем «занято».
Даже если:

• одинаковый HTTP-код,
  
• одинаковый текст,

остаются:

• разные поля в JSON,
  
• разные stack trace’ы в debug-режиме,
  
• разные тайминги.

Отдельный привет логам и метрикам, которые пишутся только «если пользователь найден».

OSINT: вы сами всё рассказали
Очень часто формат логинов вообще не нужно угадывать.

Он уже есть:

• на странице «О команде»,
  
• в PDF-презентации,
  
• в примерах в документации,
  
• на скриншотах из интерфейсов,
  
• в докладах с конференций.

Пара имён + один пример логина = гипотеза по формату.
Дальше — перебор и проверка.

Timing-атаки: когда ошибки одинаковые, а время — нет
Даже если вы сделали всё «правильно»:

• один текст,
  
• один код ответа,

можно спалиться по времени обработки.

Типичный сценарий:

• несуществующий логин → быстрый отказ;
  
• существующий логин → поиск пользователя + проверка хеша пароля.

Если используется bcrypt / scrypt / argon2 — разница может быть десятки или сотни миллисекунд.

Этого достаточно:

• делается серия запросов,
  
• считается среднее время,
  
• логины с «длинным» ответом помечаются как валидные.

Что реально помогает

• При user not found всё равно выполнять хеширование (на заглушке).
  
• Следить, чтобы логирование и метрики не добавляли разницу.
  
• Добавлять jitter или фиксированную задержку там, где это допустимо.
  
• Не забывать, что API и UI — разные поверхности атаки.

Здесь классика жанра:

Правильно:

На практике:

• «Пользователь не найден»,
  
• письмо отправляется только для существующих,
  
• разный тайминг ответа.

Регистрация и «логин занят»
Проверка занятости логина в реальном времени — почти всегда утечка.

Особенно если:

• нет капчи,
  
• нет лимитов,
  
• нет задержек.

Лучше:

• проверять занятость только при финальной отправке,
  
• ограничивать частоту,
  
• не говорить явно, почему регистрация не прошла.

Про шаблоны логинов и «случайные» имена
Форматы name.family, n.family, family.n, name.f удобны.
И именно поэтому опасны.

Как только они где-то засветились вместе с реальными именами, атакующий получает:

• формат,
  
• кандидатов,
  
• способ проверки.

Даже если это было «просто для примера».
Итог
User enumeration — это не уязвимость.
Но позволяя её воспроизводить, мы сделали атаку проще.

Чем меньше различий:

• в текстах,
  
• в кодах,
  
• во времени ответа,

и чем меньше реальных примеров и шаблонов в открытом доступе —
тем меньше полезных сигналов вы отдаёте наружу.

Мы в Dungleton Security регулярно проверяем такие вещи на наших системах - и почти всегда что-то находится.

Пишите мне нам на email, если у вас есть вопросы, с Вами были Эмили Браун и Павел Чернов, до встречи на PHDays 2026!

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