Предотвращение входа в систему Brute Force на веб-сайтах

Ответ 1

Я думаю, что короткий период блокировки базы данных для данной учетной записи (1-5 минут) - единственный способ справиться с этим. Каждый userid в вашей базе данных содержит timeOfLastFailedLogin и numberOfFailedAttempts. Когда numbeOfFailedAttempts > X вы блокируете в течение нескольких минут.

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

Существует по крайней мере одна целая страна NAT в Азии, поэтому IP-адрес нельзя использовать ни для чего.

Ответ 2

В моих глазах есть несколько возможностей, у каждого есть минусы и плюсы:

Формирование безопасных паролей

• Pro: предотвратит атаки словаря
• Con: также будет препятствовать распространению популярности, поскольку большинство пользователей не могут запоминать сложные пароли, даже если вы объясните им, как их легко запомнить. Например, вспомнив предложения: "Я купил 1 яблоко за 5 центов в торговом центре", приводит к "Ib1Af5CitM".

Блокировки после нескольких попыток

• Pro: замедлит автоматические тесты
• Кон. Легко заблокировать пользователей для третьих лиц.
• Кон. Обеспечение постоянной работы в базе данных может привести к большому количеству процессов записи в таких огромных сервисах, как Twitter или сопоставимые.

CAPTCHAs

• Pro: они предотвращают автоматическое тестирование
• Кон: они потребляют вычислительное время
• Кон: "замедлит" работу пользователя.
• HUGE CON: они НЕ БЕЗОПАСНО

Простые проверки знаний

• Pro: предотвратит автоматическое тестирование
• Con: "Простой" находится в глазу наблюдателя.
• Кон: "замедлит" работу пользователя.

Различные логин и имя пользователя

• Pro. Это одна техника, которую вряд ли можно увидеть, но в моих глазах неплохо начать предотвращать атаки грубой силы.
• Кон: зависит от выбора пользователями двух имен.

Использовать целые предложения как пароли

• Pro. Увеличивает размер доступного пространства возможностей.
• Pro: легче запомнить для большинства пользователей.
• Кон: зависит от выбора пользователей.

Как вы можете видеть, "хорошие" решения зависят от выбора пользователей, что снова показывает пользователя как самый слабый элемент цепочки.

Любые другие предложения?

Ответ 3

Вы можете делать то, что делает Google. Что происходит после определенного количества попыток, у них появляется пленкача. Затем, через пару раз с помощью капача, вы запираете их на пару минут.

Ответ 4

Я согласен с большинством других комментариев:

• Блокировка после неудачных попыток с ошибкой X
• Счет неудачных попыток с именем пользователя
• При необходимости используйте CAPTCHA (например, попытки 1-2 являются нормальными, попытки 3-5 являются CAPTCHA'd, дальнейшие попытки блокируются в течение 15 минут).
• При необходимости отправьте электронное письмо владельцу учетной записи, чтобы удалить блок

Я хотел бы отметить, что вы должны быть очень осторожны в том, чтобы форсировать "сильные" пароли, поскольку это часто означает, что они будут просто записаны на столбе на столе/прикреплены к монитору. Кроме того, некоторые политики паролей приводят к более прогнозируемым паролям. Например:

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

Скажем, вы ограничиваете его еще больше: должно быть не менее 8 символов, не может иметь последовательных букв, должно иметь букву, номер и специальный символ (это настоящая политика паролей, которую многие считают безопасным). Попытка проникнуть на счет Джона Куинси Смита? Знаете, он родился 6 марта? Там хороший шанс, что его пароль - это что-то вроде jqs0306! (или, может быть, jqs0306 ~).

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

Ответ 5

Чтобы разработать наилучшую практику:

Что сказал krosenvold: log num_failed_logins и last_failed_time в таблице пользователя (кроме случаев, когда пользователь приостановлен), и как только количество неудачных входов в систему достигает трещины, вы приостанавливаете пользователя на 30 секунд или минуту. Это лучшая практика.

Этот метод эффективно устраняет одноразовые перетаскивания и словарные атаки. Однако это не мешает злоумышленнику переключаться между именами пользователей - то есть. фиксируя пароль и пытаясь его с большим количеством имен пользователей. Если на вашем сайте достаточно пользователей, такая атака может продолжаться долгое время, пока не закончится несважаемые учетные записи. Хотелось бы надеяться, что он будет запускать эту атаку с одного IP (вряд ли, поскольку ботнеты действительно становятся инструментом торговли в эти дни), поэтому вы можете обнаружить это и заблокировать IP, но , если он распространяет атаку... ну, это еще один вопрос (который я только что разместил здесь, поэтому, пожалуйста, проверьте его, если вы этого не сделали).

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

И вы МОЖЕТЕ, по крайней мере, двумя способами.

• Если пользователь имеет постоянный логин ( "помни меня" ), просто разреши его пройти.

• Когда вы показываете сообщение "Извините, ваша учетная запись приостановлена ​​из-за большого количества неудачных попыток входа в систему", добавьте ссылку, в которой говорится: " безопасный вход в систему резервного копирования - ТОЛЬКО ЧЕЛОВЕК (боты: нет лжи). Шутка в сторону, когда они нажимают на эту ссылку, дайте им регистрационную форму с подтверждением reCAPTCHA, в которой обходит статус приостановки учетной записи. Таким образом, если они являются человеческими И знают правильный логин + пароль (и могут читать CAPTCHA), они никогда не будут беспокоиться о задержках, и ваш сайт будет непроницаем для быстрых атак.

Только недостаток: некоторые люди (например, люди с ослабленным зрением) не могут читать CAPTCHA, и они МОГУТ все еще пострадать от раздражающих задержек, вызванных ботом, если они не используют функцию автологина.

ЧТО НЕ НЕИСПРАВНО: что у автологического файла cookie нет встроенной встроенной функции безопасности. Почему же это не недостаток, спросите вы? Поскольку до тех пор, как вы его реализовали с умом, безопасный токен (эквивалент пароля) в вашем cookie файле входа в два раза больше бит (черт, сделайте это в десять раз больше бит!) В качестве вашего пароля, так что грубая фактически не проблема. Но если вы действительно параноик, настройте односекундную задержку на функцию автологина, просто для хорошей меры.

Ответ 6

Для этой цели вы должны реализовать кэш в приложении, не связанном с вашей базой данных.

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

Вторым, в зависимости от вашего приложения, вы можете быть немного умнее с контрмерами, специфичными для приложений, чем вы могли бы захотеть хранить данные в БД.

Устойчив к высокоскоростным попыткам, которые будут вытеснять состояние DOS в ваш backdb.

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

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

Ответ 7

Как и большинство банков, заблокируйте имя пользователя/учетную запись после неудачных попыток входа в систему. Но я не был бы столь строгим, как банк, в котором вы должны позвонить, чтобы разблокировать свою учетную запись. Я бы просто сделал временную блокировку из 1-5 минут. Если, конечно, веб-приложение не является чувствительным к данным, как банк.:)

Ответ 8

Думаю, вам нужно снова ввести имя пользователя. Это единственная константа (что-то еще может быть подделано). И да, это может заблокировать законного пользователя в течение дня. Но если я должен выбрать между взломанной учетной записью и закрытой учетной записью (на день), я определенно выбрал блокировку.

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

Ответ 9

Это старый пост. Однако я подумал о том, чтобы разместить здесь свои выводы, чтобы они могли помочь любому будущему разработчику.

Нам нужно предотвратить атаку методом "грубой силы", чтобы злоумышленник не смог получить имя пользователя и пароль для входа на веб-сайт. Во многих системах они имеют некоторые открытые URL-адреса, для которых не требуется токен аутентификации или ключ API для авторизации. Большинство из этих API являются критическими. Например; API для регистрации, входа в систему и забытого пароля часто открыты (т.е. не требует проверки токена аутентификации). Мы должны убедиться, что услуги не злоупотребляют. Как указывалось ранее, я просто размещаю свои выводы здесь, изучая, как мы можем эффективно предотвратить атаку методом перебора.

Большинство общих методов профилактики уже обсуждаются в этом посте. Я хотел бы добавить свои опасения в отношении блокировки учетной записи и IP-адреса. Я думаю, что блокировка учетных записей - плохая идея как метод предотвращения. Я помещаю некоторые пункты здесь, чтобы поддержать мое дело.

Плохая блокировка аккаунта

• Злоумышленник может вызвать отказ в обслуживании (DoS), заблокировав большое количество учетных записей.
• Поскольку вы не можете заблокировать учетную запись, которая не существует, блокируются только действительные имена учетных записей. Злоумышленник может использовать этот факт для сбора имен пользователей с сайта, в зависимости от ответов об ошибках.
• Злоумышленник может отвлечь внимание, заблокировав множество учетных записей и наполнив службу поддержки звонками в службу поддержки.
• Злоумышленник может постоянно блокировать одну и ту же учетную запись, даже через несколько секунд после того, как администратор разблокирует ее, эффективно отключая ее.
• Блокировка учетной записи неэффективна против медленных атак, которые каждый час пробуют только несколько паролей.
• Блокировка учетной записи неэффективна для атак, которые пытаются использовать один пароль для большого списка имен пользователей.
• Блокировка учетной записи неэффективна, если злоумышленник использует комбинированный список имени пользователя и пароля и правильно угадывает с первой пары попыток.
• Мощные учетные записи, такие как учетные записи администратора, часто обходят политику блокировки, но они являются наиболее желательными учетными записями для атаки. Некоторые системы блокируют учетные записи администраторов только при сетевых входах в систему.
• Даже после того, как вы заблокируете учетную запись, атака может продолжиться, потребляя ценные человеческие и компьютерные ресурсы.
• Например, рассмотрим аукционный сайт, на котором несколько участников сражаются за один и тот же предмет. Если на веб-сайте аукциона предусмотрена блокировка аккаунта, один участник может просто заблокировать аккаунты других в последнюю минуту аукциона, не давая им возможности подать любые выигрышные заявки. Злоумышленник может использовать ту же технику, чтобы заблокировать критические финансовые транзакции или переписку по электронной почте.

Блокировка IP-адреса для учетной записи тоже плохая идея

Другим решением является блокировка IP-адреса с несколькими неудачными входами в систему. Проблема с этим решением состоит в том, что вы можете непреднамеренно заблокировать большие группы пользователей, заблокировав прокси-сервер, используемый поставщиком услуг Интернета или крупной компанией. Другая проблема заключается в том, что многие инструменты используют списки прокси-серверов и отправляют только несколько запросов с каждого IP-адреса, прежде чем перейти к следующему. Используя широко доступные списки открытых прокси на таких веб-сайтах, как http://tools.rosinstrument.com/proxy/, злоумышленник может легко обойти любой механизм блокировки IP. Поскольку большинство сайтов не блокируются после одного неудачного пароля, злоумышленник может использовать две или три попытки для одного прокси. Злоумышленник со списком из 1000 прокси-серверов может попытаться заблокировать 2000 или 3000 паролей. Тем не менее, несмотря на недостатки этого метода, сайты, которые подвергаются большому количеству атак, в частности сайты для взрослых, предпочитают блокировать IP-адреса прокси.

Мое предложение

• Не блокировка аккаунта. Вместо этого мы могли бы рассмотреть возможность добавления преднамеренной задержки со стороны сервера при попытках входа/регистрации для последовательных неправильных попыток.
• Отслеживание местоположения пользователя на основе IP-адреса при попытках входа в систему, что является обычной техникой, используемой Google и Facebook. Google отправляет OTP, в то время как Facebook предоставляет другие проблемы безопасности, такие как обнаружение друзей по фотографиям.
• Google re-captcha для веб-приложения, SafetyNet для Android и соответствующая техника аттестации мобильных приложений для iOS - в запросах на вход в систему или регистрацию.
• Файл cookie устройства
• Создание системы мониторинга вызовов API для обнаружения необычных вызовов для определенной конечной точки API.

Объясненные предложения

Преднамеренная задержка ответа

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

Обратите внимание, что хотя добавление задержки может замедлить однопоточную атаку, она менее эффективна, если злоумышленник отправляет несколько одновременных запросов аутентификации.

Проблемы безопасности

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

Мы могли бы рассмотреть вопрос о включении, когда мы будем бросать вызовы безопасности? Есть несколько моментов, где мы можем.

• Когда пользователь пытается войти из местоположения, где он не был расположен поблизости раньше.
• Неправильные попытки входа в систему.

С какой проблемой безопасности может столкнуться пользователь?

• Если пользователь задает вопросы безопасности, мы могли бы подумать о том, чтобы спросить у пользователя ответы на них.
• Для таких приложений, как Whatsapp, Viber и т.д. Мы могли бы рассмотреть возможность выбора случайных имен контактов из телефонной книги и попросить ввести их номера или наоборот.
• Для транзакционных систем, мы могли бы рассмотреть вопрос о запросе пользователя о последних транзакциях и платежах.

Панель мониторинга API

Построить панель мониторинга для вызовов API.

• Ищите условия, которые могут указывать на атаку грубой силой или другое злоупотребление учетной записью в панели мониторинга API.
• Многие неудачные входы с одного IP-адреса.
• Вход в систему с несколькими именами пользователей с одного IP-адреса.
• Вход для одной учетной записи осуществляется с разных IP-адресов.
• Чрезмерное использование и потребление пропускной способности от одного использования.
• Неудачные попытки входа в систему с использованием алфавитно-последовательных имен пользователей или паролей.
• Логины с подозрительными паролями, которые обычно используют хакеры, такие как ownsyou (ownzyou), washere (wazhere), фанатики, hacksyou и т.д.

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

Вот некоторые хорошие чтения.

• https://en.wikipedia.org/wiki/Brute-force_attack#Reverse_brute-force_attack
• https://www.owasp.org/index.php/Blocking_Brute_Force_Attacks
• http://www.computerweekly.com/answer/Techniques-for-preventing-a-brute-force-login-attack

Ответ 10

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

Какова сумма 2 и 2?

И если вы запишете последний сбой входа в систему, вы можете пропустить CAPTCHA, если он достаточно стар. Только выполнить тест CAPTCHA, если последний сбой произошел за последние 10 минут.

Ответ 11

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

Лучшая защита от атаки со словарем - убедиться, что пароли не находятся в словаре! В основном настраивается какая-то политика паролей, которая проверяет словарь на букву и требует номер или символ в пароле. Вероятно, это лучшая защита от атаки словаря.

Ответ 12

Для среды .NET

Динамические ограничения IP

Расширение динамических IP-ограничений для IIS предоставляет ИТ-специалистам и хостерам настраиваемый модуль, который помогает смягчать или блокировать атаки на отказ в обслуживании или взламывать пароли через Brute-force, временно блокируя IP-адреса HTTP-клиентов, которые следуют которая могла бы способствовать одной из таких атак. Этот модуль можно настроить таким образом, чтобы анализ и блокировка выполнялись на веб-сервере или на уровне веб-сайта.

Уменьшить вероятность атаки "Отказ в обслуживании" путем динамической блокировки запросов со вредоносных IP-адресов

Динамические ограничения IP для IIS позволяют снизить вероятность того, что ваш веб-сервер подвергнется атаке "Отказ в обслуживании", проверив IP-адрес источника запросов и идентифицируя шаблоны, которые могут сигнализировать о нападении. Когда обнаружен шаблон атаки, модуль поместит нарушающий IP-адрес в список временного запрета и не будет отвечать на запросы в течение заданного промежутка времени.

Сведите к минимуму возможности взлома паролей вашего веб-сервера Brute-force

Динамические ограничения IP для IIS способны обнаруживать шаблоны запросов, которые указывают, что пароли веб-сервера пытались декодироваться. Модуль поместит нарушающий IP-адрес в список серверов, которым запрещен доступ в течение заданного промежутка времени. В ситуациях, когда аутентификация выполняется в отношении служб Active Directory (ADS), модуль может поддерживать доступность веб-сервера, избегая необходимости выдавать проблемы с проверкой подлинности для ADS.

Функции

• Полная интеграция в диспетчере IIS 7.0.

• Динамическая блокировка запросов с IP-адреса по одному из следующих критериев:

  • Количество одновременных запросов.

  • Количество запросов за определенный промежуток времени.

• Поддержка списка IP-адресов, которым разрешено обходить фильтрацию динамического IP-ограничения.

• Блокирование запросов может быть настроено на уровне веб-сайта или веб-сервера.

• Настраиваемые действия запрета позволяют ИТ-администраторам указывать, какой ответ будет возвращен клиенту. Модуль поддерживает коды состояния возврата 403, 404 или закрывает соединение.

• Поддержка адресов IPv6.

• Поддержка веб-серверов за прокси-сервером или брандмауэром, которые могут изменять IP-адрес клиента.

http://www.iis.net/download/DynamicIPRestrictions

Ответ 13

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

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

При входе пользователя в систему в первый раз. Мы создаем сеанс вроде

$_SESSION['loginFail'] = 10; // any number you prefer

Если успех входа в систему, мы уничтожим его и позволим пользователю войти в систему.

unset($_SESSION['loginFail']); // put it after create login session

Но если пользователь терпит неудачу, поскольку мы обычно отправляем сообщение об ошибке, в то же время мы сокращаем сеанс на 1:

$_SESSION['loginFail']-- ; // reduce 1 for every error

и если пользователь сработает 10 раз, мы направим их на другой веб-сайт или на любые веб-страницы.

if (!isset($_SESSION['loginFail'])) { 

     if ($_SESSION['login_fail'] < 1 ) {

     header('Location:https://google.com/'); // or any web page

     exit();

}
}

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

Пользователи должны закрыть браузер (чтобы уничтожить сеанс loginFail, который мы создали), откройте его снова, чтобы снова увидеть нашу страницу входа.

Это полезно?

Ответ 14

Есть несколько аспектов, которые следует учитывать, чтобы предотвратить грубую силу. рассмотреть данные аспекты.

1. Надежность пароля

   Заставить пользователей создать пароль, соответствующий определенным критериям

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

   Создав политику минимальной надежности пароля, brute-force потребуется время, чтобы угадать пароль. Между тем, ваше приложение может идентифицировать такую вещь и перенести ее.

2. ReCaptcha

   Вы можете использовать reCaptcha, чтобы скрипты ботов не имели функции грубой силы. Это довольно легко реализовать reCaptcha в веб-приложении. Вы можете использовать Google reCaptcha. он имеет несколько разновидностей reCaptcha, таких как Invisible reCaptcha и reCaptcha v3.

3. Политика динамической IP-фильтрации

   Вы можете динамически идентифицировать шаблон запроса и заблокировать IP, если шаблон соответствует критерию вектора атаки. Одним из самых популярных методов фильтрации попыток входа является Throttling. Прочитайте метод регулирования, используя php, чтобы узнать больше. Хорошая политика динамической IP-фильтрации также защищает вас от таких атак, как DoS и DDos. Однако это не помогает предотвратить DRDos.

4. Механизм предотвращения CSRF

   csrf известен как cross-site request forgery. Означает, что другие сайты отправляют формы на ваш PHP скрипт/контроллер. Laravel имеет довольно четкий подход к предотвращению csrf. Однако, если вы не используете такую платформу, вы должны разработать свой собственный механизм предотвращения csrf JWT. Если ваш сайт защищен CSRF, то у вас нет шансов запустить грубую силу в любых формах на вашем сайте. Это как главные ворота, которые ты закрыл.