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

17

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

  1. Заблокировать пользователя после неудачных попыток входа в систему. Проблема: легко превратиться в атаку отказа в обслуживании, за короткое время заблокировать многих пользователей.
  2. Интенсивное увеличение времени ответа на неудачную попытку входа в систему по имени пользователя. Проблема: словарные атаки могут использовать один и тот же пароль, но разные имена пользователей.
  3. Интенсивное увеличение времени ответа на неудачную попытку входа в систему с IP-адреса. Проблема: легко обойти, спуская IP-адрес.
  4. Интенсивное увеличение времени ответа на неудачную попытку входа в сеанс. Проблема: легко обойтись, создав атаку словаря, которая запускает новый сеанс при каждой попытке.
задан Kevin Pang 07.05.2010 в 08:28
источник
  • Не изобретайте велосипед, смотрите, как это делают другие веб-приложения. Почему бы не использовать капчу? –  Konerak 07.05.2010 в 08:31

8 ответов

21

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

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

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

ответ дан rook 07.05.2010 в 08:42
3

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

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

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

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

    
ответ дан EMP 07.05.2010 в 08:47
1

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

    
ответ дан Felix 07.05.2010 в 08:31
1

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

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

    
ответ дан Thomas 07.05.2010 в 08:37
1

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

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

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

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

    
ответ дан Eadwacer 07.05.2010 в 18:49
  • Не означает ли такая система, что человек, который знает IP-адрес другого пользователя игры, может отключить IP-адрес посредством подмены IP-адресов? –  Christian 11.05.2010 в 23:13
  • @Christian: Нет, потому что TCP использует трехстороннее рукопожатие для установления соединения, и это не может быть завершено поддельным адресом, потому что злоумышленник не получит ACK сервера. (Он будет отправлен на фиктивный IP-адрес, а не на реальный адрес злоумышленника.) Без установления соединения с поддельным адресом злоумышленник не сможет попытаться выполнить вход с этого адреса. –  Dave Sherohman 11.05.2010 в 23:26
1

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

Ссылка

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

    
ответ дан Jim Carnicelli 07.11.2012 в 02:07
0

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

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

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

    
ответ дан 0concern 11.05.2010 в 22:57
  • Как бы хеш соли и пароля уменьшал эффективность атаки словаря? Солить и хеширование - насколько мне известно, полезны только для шифрования пароля, чтобы он не был сохранен в виде обычного текста в базе данных. В конце концов, плохо выбранный пароль по-прежнему будет уязвим для атаки словаря, независимо от того, соленали ли они и хэшировали перед хранением. –  Kevin Pang 12.05.2010 в 00:24
0

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

    
ответ дан Christian 11.05.2010 в 23:09