Предотвращение тайминговых атак при аутентификации (входе) в приложении на nodejs

Вопрос или проблема

Я использую GraphQL, и моя функция входа выполняется с помощью промиса. Имя пользователя – это адрес электронной почты.

Шаги в логике следующие: –

Проверить токен CRSF, в противном случае вернуть общее сообщение (“Неверное имя пользователя или пароль”).
Проверить, что формат электронной почты действителен, в противном случае вернуть общее сообщение.
Проверить, что формат пароля действителен, в противном случае вернуть общее сообщение.
Выбрать запись пользователя из БД, где email = входящий email.
Если запись не найдена, вернуть общее сообщение.
Если запись найдена, сравнить хеш входящего пароля с хешем пароля в найденной записи пользователя. Если совпадает, выполнить вход, иначе вернуть общее сообщение.

Предполагается, что хеширование пароля – это самая времязатратная часть. Я рассматриваю 2 подхода: –

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

Есть ли у кого-нибудь мнения по поводу того, какой из этих 2 методов будет лучше для этого сценария? Спасибо.

Ответ или решение

Чтобы предотвратить тайминг-атаки аутентификации (логина) в приложении на Node.js с использованием GraphQL, необходимо внимательно рассмотреть ваши текущие шаги аутентификации и предложенные методы защиты.

1. Общая концепция тайминг-атак

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

2. Ваш текущий процесс аутентификации

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

3. Предложенные методы защиты

Вы упомянули два метода для минимизации риска тайминг-атак:

Метод 1: Генерация случайной строки и хеширование

Этот метод предполагает хеширование случайной строки на этапе запроса данных о пользователе (пункт 4). Если запись не найдена, вы возвращаете несуществующий хеш, вместо того чтобы возвращать информацию о том, что пользователь не найден. Таким образом, это сбивает с толку потенциального атакующего и делает время ответа практически одинаковым, независимо от результатов проверки.

Метод 2: Стандартная задержка

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

4. Рекомендации и выводы

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

Использование метода случайной строки: Он действительно позволяет создать эффект дополнительного замешательства у потенциального атакующего и сделать вашу систему менее уязвимой. Обязательно используйте криптографически безопасные методы генерации случайных данных для повышения надежности.
Скорректировать длительность ожидания: Если вы вводите стандартные задержки, учитывайте, что слишком долгое ожидание может негативно сказаться на пользовательском опыте. Рассматривайте возможность использования адаптивного времени ожидания, зависящего от сложности или нагрузки системы.
Мониторинг и логирование: Внедрите систему мониторинга для отслеживания подозрительной активности. Логи следует анализировать на предмет аномалий и повторяющихся попыток входа.
Обновление библиотек и поддержание безопасности: Убедитесь, что используемые вами библиотеки и фреймворки всегда актуальны и безопасны от известных уязвимостей.

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