Предотвращение атак с подбором по словарю на веб-приложении
Что лучший способ состоит в том, чтобы предотвратить атаку с подбором по словарю? Я продумал несколько реализаций, но у них всех, кажется, есть некоторый дефект в них:
- Заблокируйте пользователя после X неудавшихся попыток входа в систему. Проблема: легкий превратиться в атаку "отказ в обслуживании", блокируя многих пользователей в короткий срок.
- Инкрементно увеличьте время отклика на неудавшуюся попытку входа в систему на имени пользователя. Проблема: атаки с подбором по словарю могли бы использовать тот же пароль, но различные имена пользователей.
- Инкрементно увеличьте время отклика на неудавшуюся попытку входа в систему от IP-адреса. Проблема: легкий двигаться путем спуфинга IP-адреса.
- Инкрементно увеличьте время отклика на неудавшуюся попытку входа в систему в рамках сессии. Проблема: легкий двигаться путем создания атаки с подбором по словарю, которая разжигает новую сессию на каждой попытке.
7 ответов
Мне очень нравится система защиты от грубой силы Gmail. Он основан на «тепле», которое пользователь может накапливать, после того, как пользователь перегрелся, ему предлагается ввести код. Вы можете отслеживать температуру с помощью базы данных sql или с помощью redis incr . Тепло назначается IP-адресу. На 100% невозможно "подделать" TCP-соединение через Интернет из-за трехстороннего рукопожатия , однако прокси-серверов много, а IP-адреса очень дешевы. Прокси-серверы обычно используются для рассылки спама, вы можете проверить черный список и автоматически запросить у них ввод кода.
Каждое неверное действие против вашей системы будет обновлять таблицу забега. Например, неудачный вход в систему накапливает 35% тепла. Как только уровень тепла станет больше или равен 100%, пользователь будет вынужден решить капчу. Решение капчи «охладит» этот IP-адрес. Таблица забега может содержать столбец с отметкой времени, в котором при обновлении устанавливается текущее время. Примерно через 24 часа температура может вернуться к нулю.
reCaptcha - самая безопасная капча, которую вы можете использовать.
Я всегда был поклонником вашего варианта 3 - блокировка или дросселирование клиента на основе его IP-адреса. Все остальные варианты - это больше проблем, чем пользы по указанным вами причинам.
Подмена IP-адреса возможна, но она не побеждает эту контрмеру. Если вы имеете в виду "спуфинг" в техническом смысле - подделка заголовка TCP-пакета - то это не принесет злоумышленнику большой пользы, потому что даже если он угадает правильный пароль, он не получит ответ, который сообщит ему об этом. Конечно, они все еще могут использовать прокси-серверы, но их количество ограничено. Даже если в распоряжении злоумышленника 1000 работающих прокси, а вы разрешаете 10 попыток для каждого IP, то это 10 000 попыток. Если вы обеспечите хоть какую-то сложность пароля (например, потребуете буквенно-цифровой пароль), этого будет недостаточно, чтобы угадать много.
Одного этого должно быть достаточно, чтобы остановить большинство скрипт-кидди. Если вы противостоите более решительному злоумышленнику, то, вероятно, вам придется внедрить какой-то мониторинг всего сайта, который определит, что попыток много (значит, вероятно, идет атака) и "заблокирует" каким-то образом, например, с помощью CAPTCHA. Я не сторонник постоянного использования CAPTCHA - они вызывают больше раздражения, чем пользы.
В конечном счете, выбор надежного пароля зависит от пользователя (хотя вы можете ему помочь). Если пользователь выбрал в качестве пароля "Password1", то ничто, что вы можете сделать, не помешает хакеру взломать его аккаунт.
Возможно, вам нужно внедрить CAPTCHA в ваши веб-формы.
Есть вечный компромисс между безопасностью, доступностью и удобством использования, а это означает, что идеального решения не существует.
Приличный компромисс, в зависимости от вашей ситуации, - использовать вариант №1 с капчей. Заблокируйте учетную запись после трех неудачных попыток, но разрешите последующие попытки входа в систему, если капча решена правильно.
Я бы также рекомендовал использовать вариант 3. Хотя он не так хорош против злоумышленника с большим количеством прокси (или бот-сетью), я все же думаю, что это лучший ответ для большинства сайтов. (Gmail имеет разные угрозы от большинства сайтов, поэтому требует разных ответов.)
Пример из реальной жизни:
Большая онлайн-игра, в которой я участвую, отслеживает, сколько неудачных попыток входа поступает с каждого IP-адреса в последние 5 минут. В тот момент, когда любой IP-адрес накапливает 5 неудачных попыток входа в систему (независимо от количества успешных попыток), этот адрес блокируется на 45 минут.
Почему это работает
Я сел и решил, что очень умный хакер сможет взломать учетную запись со словарем примерно в 1 из 100 попыток (вероятно, намного хуже). Таким образом, в худшем случае злоумышленник взламывает 1 учетную запись каждые 100 минут (на каждый IP-адрес). Для угроз, направленных против этого конкретного сайта, этой защиты было достаточно. Наши аккаунты на самом деле не так дорого стоят. Вам необходимо определить (для вашего сайта), какой уровень защиты вам нужен. Вы можете увеличить это окно до 30 минут, если хотите, чтобы оно длилось в 3 раза дольше, если вам нужно.
Важное примечание
Не не сбрасывать счетчики (будь то решение 3 или тепловая карта, описанная выше) после успешного входа в систему. Если вы это сделаете, злоумышленник просто попытается взломать 3 учетные записи, а затем успешно войдет в какую-либо учетную запись, которую он уже контролирует (свою или уже взломанную), и никогда не будет заблокирован.
Это зависит от того, что вы подразумеваете под "предотвратить".
Если вы не хотите, чтобы они тратили вашу пропускную способность, дросселирование, блокировка и т.д. являются жизнеспособными вариантами. С тепловыми таблицами есть накладные расходы - вам нужно создавать и поддерживать логику, хранить и администрировать "тепловые карты", и т.д. и т.п. Я также видел некоторые системы, основанные на геолокации ip-адресов, которые выдают капчу или изменяют профиль входа, если пользователь пытается войти с "удаленного" или "неизвестного" ip-адреса.
Если вы просто хотите значительно снизить эффективность атак по словарю, используйте соль в дополнение к хэшам паролей.
Вы можете запретить пароли, содержащие словарные слова, если вы программируете для приложения, где безопасность действительно важна. Вам не нужно разрешать QWERTY в качестве действительного пароля.