Предотвращение атак на словаря в веб-приложении

Какой лучший способ предотвратить атаку словаря? Я придумал несколько реализаций, но все они, похоже, имеют некоторые недостатки:

Заблокировать пользователя после неудачных попыток входа в систему. Проблема: легко превратиться в атаку отказа в обслуживании, за короткое время заблокировать многих пользователей.
Интенсивное увеличение времени ответа на неудачную попытку входа в систему по имени пользователя. Проблема: словарные атаки могут использовать один и тот же пароль, но разные имена пользователей.
Интенсивное увеличение времени ответа на неудачную попытку входа в систему с IP-адреса. Проблема: легко обойти, спуская IP-адрес.
Интенсивное увеличение времени ответа на неудачную попытку входа в сеанс. Проблема: легко обойтись, создав атаку словаря, которая запускает новый сеанс при каждой попытке.

Ответ 1

Мне очень нравится система групповой борьбы с gmail. Он основан на "нагреве", который пользователь может накапливать, после того, как пользователь перегрелся, ему будет предложено ввести капчу. Вы можете отслеживать тепло, используя базу данных sql, или используя redis incr. Тепло присваивается IP-адресу. На 100% невозможно "подделать" tcp-соединение через интернет из-за трехстороннее рукопожатие, однако прокси-серверы в изобилии и ip-адрес очень дешевы. Прокси-серверы обычно используются для отправки спама, вы можете проверить черный список и автоматически запросить их для получения исправления.

Каждое плохое действие против вашей системы будет обновлять таблицу тепла. Например, неудачный логин будет накапливать 35% тепла. Как только уровень тепла будет больше или равен 100%, тогда пользователь вынужден решить капчу. Решение captcha будет "охлаждать" этот IP-адрес. Таблица тепла может содержать столбец временной метки, который установлен на текущее время при обновлении. Через 24 часа тепло может вернуться к 0.

reCaptcha - это самый безопасный captcha, который вы можете использовать.

Ответ 2

Я всегда был поклонником вашего варианта 3 - блокировки или дросселирования клиента на основе его IP-адреса. Другие варианты - все больше проблем, чем они заслуживают по причинам, о которых вы заявили.

Возможна подмена IP-адреса, но она не отменяет эту встречную меру. Если вы имеете в виду "спуфинг" в техническом смысле - подделку заголовка TCP-пакета, то это не сделает злоумышленнику много хорошего, потому что даже если они угадают правильный пароль, они не получат ответ, который им так говорит. Конечно, они все равно могут использовать прокси, но количество прокси-серверов ограничено. Даже если у злоумышленника есть 1000 рабочих прокси, и вы разрешаете 10 попыток на IP, что 10 000 попыток. Если вы вообще применяете какую-либо сложность паролей (например, требуя буквенно-цифровой пароль), этого недостаточно, чтобы догадываться.

Этого должно быть достаточно, чтобы остановить большинство детей script. Если вы столкнулись с более решительным злоумышленником, вам, вероятно, придется реализовать какой-то мониторинг на сайте, который обнаруживает, что есть много попыток (поэтому, вероятно, происходит атака) и "блокируется" каким-то образом, например, используя CAPTCHA. Я не поклонник использования CAPTCHA все время - они просто больше раздражают, чем они того стоят.

В конечном счете, пользователь должен выбрать безопасный пароль (хотя вы можете им помочь). Если они выбрали "Пароль1" в качестве своего пароля, то ничего, что вы можете сделать, не позволит хакеру проникнуть в их аккаунт.

Ответ 3

Возможно, вам нужно реализовать CAPTCHA в ваших веб-формах.

Ответ 4

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

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

Ответ 5

Я бы также рекомендовал использовать вариант 3. Хотя это не так хорошо против злоумышленника с большим количеством прокси (или бот-сети), я по-прежнему считаю, что это лучший ответ для большинства сайтов. (Gmail имеет разные угрозы от большинства сайтов, поэтому ему нужны разные ответы.)

Пример реального мира:
Большая онлайн-игра, в которой я участвую, отслеживает количество неудачных попыток входа в систему с каждого IP-адреса за последние 5 минут. В тот момент, когда каждый IP-адрес накапливает 5 неудачных попыток входа в систему (независимо от количества успешных попыток), этот адрес блокируется в течение 45 минут.

Почему это работает Я сел и решил, что очень умный хакер сможет сломать учетную запись со словарем около 1 из каждых 100 попыток (возможно, намного хуже). Таким образом, в худшем случае сценарий взлома 1 разыгрывается каждые 100 минут (по IP-адресу). Для угроз на этом конкретном сайте это была достаточная защита. Наши счета действительно не стоят того. Вам необходимо определить (для вашего сайта), какую защиту вам нужно. Вы можете увеличить окно до 30 минут, если вы захотите сделать его в 3 раза длиннее, если вам нужно.

Важное примечание
Не удаляйте reset (будь то решение 3 или тепловая карта, описанная выше) после успешного входа в систему. Если вы это сделаете, злоумышленник просто попытается взломать 3 учетных записи, а затем успешно зарегистрируется на какой-либо учетной записи, которую они уже контролируют (их или уже скомпрометированной учетной записи) и никогда не будет дросселироваться.

Ответ 6

Во-первых, запретите пользователям выбирать общие пароли. Добавьте "черный список" в свою базу данных и проверьте новые пароли против них. Вы можете заполнить его, используя один из многих списков паролей или слов, например здесь:

http://securityoverride.org/infusions/pro_download_panel/download.php?did=66

Во-вторых, рассмотрим временную блокировку. Если у вас есть таблица "Пользователь", добавьте столбцы "LastLoginAttemptedOn" и "FailedLoginAttempts". Обновляйте эти значения каждый раз, когда пользователь пытается войти в систему. Когда пользователь успешно войдет в систему, reset FailedLoginAttempts вернется к 0. Когда FailedLoginAttempts достигнет 4 (или что вы предпочитаете), не позволяйте пользователю пытаться войти в систему на 5 минут (опять же, ваше предпочтение) от LastLoginAttemptedOn. Не обновляйте этот столбец до тех пор, пока им не удастся его попытаться предотвратить попытку reset таймера с помощью 4 минут. reset FailedLoginAttempts в 0, когда таймер сбрасывается, поэтому у них есть еще несколько попыток.

Ответ 7

Это зависит от того, что вы подразумеваете под "предотвращением".

Если вы не хотите, чтобы они тратили впустую вашу пропускную способность, дросселирование, локаут и т.д. являются жизнеспособными вариантами. Накладные расходы на тепловые столы - вам нужно создавать и поддерживать логику, хранить и администрировать "карты тепла" и т.д. И т.д. Я также видел некоторые системы, основанные на IP-геолокации, которые вызывают капчу или меняют его журнал в профиле, если пользователь пытается войти в систему из "удаленного" или "неизвестного" ip.

Если вы просто хотите значительно снизить эффективность атаки словаря, используйте соль в дополнение к хэшам паролей.

Ответ 8

Вы можете запретить пароли, содержащие слова слова, если вы программируете приложение, где безопасность действительно важна. Вам не нужно разрешать QWERTY как действительный пароль.