Предотвращение логинов грубой силы на веб-сайтах
Если вы просто хотите загрузить группу связанных классов, Spring может вам помочь.
Spring может создавать список или карту всех классов, которые реализуют данный интерфейс в одной строке кода. Список или карта будут содержать экземпляры всех классов, которые реализуют этот интерфейс.
Как говорится, в качестве альтернативы загрузке списка классов из файловой системы вместо этого нужно реализовать один и тот же интерфейс во всех классы, которые вы хотите загрузить, независимо от пакета и использовать Spring, чтобы предоставить вам все экземпляры. Таким образом, вы можете загружать (и создавать экземпляры) все классы, которые вы хотите, независимо от того, в каком пакете они находятся.
С другой стороны, если наличие всех в пакете - это то, что вы хотите, все классы в этом пакете реализуют данный интерфейс.
11 ответов
Я думаю, что сохраненный базой данных короткий период локаута для сделанного отчета (1-5 минут) является единственным способом обработать это. Каждый userid в Вашей базе данных содержит timeOfLastFailedLogin и numberOfFailedAttempts. Когда numbeOfFailedAttempts > X Вы локаут в течение нескольких минут.
Это означает, что Вы блокируете userid рассматриваемый в течение некоторого времени, но не постоянно. Это также означает обновление базы данных для каждой попытки входа в систему (если это не заблокировано, конечно), который может вызывать другие проблемы.
существует по крайней мере одна целая страна, NAT'ed в Азии, таким образом, IP не может использоваться ни для чего.
Существует несколько аспектов, которые, как будут полагать, предотвратить "в лоб". рассмотрите данные аспекты.
-
пользователи Силы пароля Strenght
для создания пароля для соответствования определенным критериям
- Пароль должен содержать по крайней мере один верхний регистр, нижний регистр, цифру и символ (специальный символ).
- Паролю нужно определить минимальную длину согласно Вашим критериям.
- Пароль не должен содержать имя пользователя или общедоступный идентификатор пользователя.
Путем создания минимальной политики надежности пароля, "в лоб", займет время для предположения пароля. между тем Ваше приложение может определить такую вещь и переместить ее.
-
reCaptcha
можно использовать reCaptcha для предотвращения сценариев бота, имеющих функцию "в лоб". Довольно легко реализовать reCaptcha в веб-приложении. Можно использовать Google reCaptcha. это имеет несколько разновидностей reCaptcha как Невидимый reCaptcha и reCaptcha v3.
-
Динамическая политика фильтрации IP
можно динамично определить шаблон запроса и заблокировать IP, если шаблон соответствует критериям вектора атаки. одна из самой популярной техники для фильтрации попыток входа в систему
Throttling. Читайте Метод Регулировки с помощью php для знания больше. Хорошая динамическая политика фильтрации IP также защищает Вас от нападений какDoSиDDos. Однако это не помогает предотвратитьDRDos. -
Механизм Предотвращения CSRF
эти
csrfизвестен какcross-site request forgery. Означает, что другие сайты отправляют формы на Вашем Сценарии PHP / Контроллер.Laravelимеет довольно четко определенный подход для предотвращенияcsrf. Однако, если Вы не используете такую платформу, необходимо разработать собственноеJWT, основывал csrf механизм предотвращения. Если Ваш сайт является Защищенным CSRF, то нет никакого шанса запуститься "в лоб" на любых формах на Вашем веб-сайте. Это точно так же, как основной логический элемент Вы закрылись.
Я склонен соглашаться с большинством других комментариев:
- Блокировка после X неудавшихся попыток пароля
- неудачные попытки количества против имени пользователя
- Дополнительно КАПЧА использования (например, попытки 1-2 нормальны, попытки 3-5, является CAPTCHA'd, дальнейшие попытки, заблокированные в течение 15 минут).
- Дополнительно посылают электронное письмо владельцу учетной записи для удаления блока
, На что я действительно хотел указать, то, что необходимо быть очень осторожны относительно принуждения "сильных" паролей, поскольку это часто означает, что они будут просто записаны на постэтом на столе / приложенные к монитору. Кроме того, некоторые политики паролей приводят к [еще 1113] предсказуемые пароли. Например:
, Если пароль не может быть никаким предыдущим используемым паролем и должен включать число, существует хороший шанс, что это будет любой общий пароль с порядковым номером после него. Если необходимо изменять пароль каждые 6 месяцев, и человек был там двумя годами, возможности являются своим паролем, что-то как password4.
Говорят, что Вы ограничиваете его еще больше: должны быть по крайней мере 8 символов, не может иметь никаких последовательных букв, должен иметь букву, число и специальный символ (это - политика действительного пароля, которую многие считали бы безопасным). Попытка ворваться в учетную запись John Quincy Smith? Знайте, что он родился 6-го марта? Существует хороший шанс, его пароль - что-то как jqs0306! (или возможно jqs0306 ~ ).
Теперь, я не говорю, что разрешение Вашим пользователям иметь пароль пароля является хорошей идеей также, просто не разыгрывайте себя, думая, что Ваши принудительные "безопасные" пароли безопасны.
Вы могли сделать то, что делает Google. Который является после определенного числа попыток у них есть captacha, обнаруживаются. Чем после пару раз с captacha Вы блокируете их в течение нескольких минут.
В моих глазах существует несколько возможностей, каждый имеющий недостатки и профессионалов:
безопасные пароли Принуждения
- Pro: предотвратит атаки с подбором по словарю
- Con: также предотвратит популярность, так как большинство пользователей не в состоянии помнить сложные пароли, даже если Вы объясняете им, как к легкому помнят их. Например, путем запоминания предложений: "Я купил 1 Apple за 5 центов в Молле", приводит к "Ib1Af5CitM".
Локауты после нескольких попыток
- Pro: замедлит автоматизированные тесты
- Con: легко заблокировать пользователей для третьих лиц
- Con: Создание их персистентный в базе данных может привести к большому количеству процессов записи в таких огромных сервисах как Twitter или comparables.
Капчи
- Pro: Они предотвращают автоматизированное тестирование
- Con: Они используют вычислительное время
- Con: "замедлит" пользовательский опыт
- ОГРОМНЫЙ CON : Они не без барьеров
Простые проверки знаний
- Pro: предотвратит автоматизированное тестирование
- Con: "Простой" находится в глазу наблюдателя.
- Con: "замедлит" пользовательский опыт
Различный вход в систему и имя пользователя
- Pro: Это - одна техника, которая едва замечена, но в моих глазах довольно хорошее начало для предотвращения атак перебором.
- Con: Зависит от пользовательского выбора двух имен.
Использование целые предложения как пароли
- Pro: Увеличивает размер доступного для поиска пространства возможностей.
- Pro: легче помнить за большинство пользователей.
- Con: Зависьте от пользовательского выбора.
, Как Вы видите, "хорошие" решения, все зависят от пользовательского выбора, который снова показывает пользователя как самый слабый элемент цепочки.
Какие-либо другие предложения?
Я думаю, что необходимо зарегистрироваться против имени пользователя. Это - единственная константа (что-либо еще может имитироваться). И да это могло заблокировать законного пользователя в течение дня. Но если я должен выбрать между взломанной учетной записью и закрытой учетной записью (в течение дня), я определенно выбрал блокировку.
Между прочим, после третьей неудачной попытки (в течение определенного времени) можно заблокировать учетную запись и отправить почту выпуска владельцу. Почта содержит ссылку для разблокирования учетной записи. Это - небольшая нагрузка на пользователе, но взломщик заблокирован. И если даже почтовая учетная запись взламывается, Вы могли бы установить предел для количества разблокирований в день.
Действительно любите большинство банков, делают, локаут имя пользователя/учетная запись после X отказов входа в систему. Но я не был бы так же строг как банк, в котором необходимо призвать для разблокирования учетной записи. Я просто сделал бы временную блокировку из 1-5 минут. Если, конечно, веб-приложение не как данные, чувствительные как банк.:)
Уточнить лучшую практику:
, Что сказанный krosenvold: зарегистрируйте num_failed_logins и last_failed_time в пользовательской таблице (кроме тех случаев, когда пользователь временно отстранен), и после того как количество неудавшихся логинов достигает treshold, Вы временно отстраняете пользователя в течение 30 секунд или минуты. Это - лучшая практика.
, Что метод эффективно устраняет единственную учетную запись и атаки с подбором по словарю "в лоб". Однако это не препятствует тому, чтобы взломщик переключился между именами пользователей - т.е. сохранил пароль зафиксированным и попробовал его большим количеством имен пользователей. Если Ваш сайт имеет достаточно пользователей, такое нападение может быть сохранено, идя в течение долгого времени, прежде чем это исчерпает неприостановленные учетные записи для удара. Хотелось бы надеяться, он будет выполнять это нападение от единственного IP (вряд ли, хотя, поскольку ботнеты действительно становятся инструментом торговли в эти дни), таким образом, можно обнаружить, что и блокируют IP, но , если он распределяет нападение... хорошо, это - другой вопрос (что я просто отправил здесь, поэтому, проверьте его, если Вы не имеете) .
Одна дополнительная вещь помнить об исходной идее состоит в том, что необходимо, конечно, все еще попытаться пропустить законного пользователя, даже в то время как учетная запись подвергается нападению и приостановлена - то есть, ЕСЛИ можно сказать реальному пользователю и боту независимо.
И Вы CAN, по крайней мере двумя способами.
-
, Если у пользователя есть персистентный вход в систему ("помнят меня") cookie, просто позвольте ему пройти.
-
, Когда Вы отображаетесь, "я сожалею, Ваш аккаунт заблокирован из-за большого количества неудачного сообщения" попыток входа в систему, включайте ссылку, в которой говорится" безопасный резервный вход в систему - ЛЮДИ ТОЛЬКО (боты: никакая ложь) ". Шутите в стороне, когда они нажимают на ту ссылку, дают им reCAPTCHA-аутентифицируемую форму входа в систему, что обходы учетная запись приостанавливает состояние. Тот путь, ЕСЛИ они люди И знают корректный login+password (и может считать КАПЧИ), они никогда не будут беспокоиться задержками, и Ваш сайт будет непроницаем для скоропалительных нападений.
Только недостаток: некоторые люди (такие как люди с ослабленным зрением) не могут считать КАПЧИ, и они МОГУТ все еще быть затронутыми раздражающими произведенными из бота задержками , ЕСЛИ они не используют функцию автовхода в систему.
, Что не ЯВЛЯЕТСЯ недостатком: то, что cookie автовхода в систему не имеет подобных мер безопасности встроенными. Почему это не недостаток, Вы спрашиваете? Поскольку, пока Вы реализовали его мудро, безопасный маркер (эквивалентный пароль) в Вашем cookie входа в систему является вдвое большим количеством битов (heck, сделайте это в десять раз больше битов!) как Ваш пароль, таким образом принуждение скота это эффективно надуманный вопрос . Но если Вы действительно параноики, настройте одну вторую задержку на функции автовхода в систему также просто в придачу.
Много форумов онлайн, в которые я вхожу онлайн, дает мне 5 попыток вхождения в учетную запись после тех 5 попыток, учетная запись заблокирована в течение часа или пятнадцати минут. Это не может быть симпатично, но это, конечно, замедлило бы атаку с подбором по словарю на одной учетной записи. Теперь ничто не останавливает атаку с подбором по словарю против нескольких учетных записей одновременно. Т.е. попробуйте 5 раз, переключитесь на различную учетную запись, попробуйте еще 5 раз, затем вернитесь позже к обсуждаемому вопросу. Но это уверенный действительно замедляет нападение.
лучшая защита против атаки с подбором по словарю должна удостовериться, что пароли не находятся в словаре!!! В основном настройте своего рода политику паролей, которая проверяет словарь по буквам и требует числа или символа в пароле. Это - вероятно, лучшая защита против атаки с подбором по словарю.
Вы могли добавить некоторую форму теста КАПЧИ. Но остерегайтесь этого, большинство из них представляет доступ, более трудный глаз или сережка повредили людей. Интересная форма КАПЧИ задает вопрос,
, Какова сумма 2 и 2?
И если Вы записываете последний отказ входа в систему, можно пропустить КАПЧУ, если это является достаточно взрослым. Только сделайте тест КАПЧИ, если последний отказ был в течение прошлых 10 минут.
Необходимо реализовать кэш в приложении не связанный с базой данных бэкенда с этой целью.
Прежде всего задержка только законные имена пользователей заставляют Вас "бросать" en-массу Ваша допустимая клиентская база, которая может сам по себе быть проблемой, даже если имя пользователя не является тесно защищенным секретом.
113-секундный в зависимости от Вашего приложения можно быть немного более умными со специализированной задержкой контрмеры, чем Вы могли бы хотеть быть с тем, чтобы хранить данные в DB.
Его стойкое к высокоскоростным попыткам, которые пропустили бы условие DOS в Ваш дб бэкенда.
Наконец приемлемо принять некоторые решения на основе IP... Если Вы видите, что единственные попытки от возможностей IP - честная ошибка по сравнению с несколькими, дюйм/с от бога знает, сколько систем можно хотеть принять другие меры предосторожности или уведомить конечного пользователя относительно теневого действия.
у Его истинных многочисленных федераций прокси могут быть крупные числа IP-адресов, зарезервированных для их использования, но большинство действительно прилагает разумное усилие для поддержания исходного адреса сроком на время в целях прежней версии, поскольку некоторые сайты имеют привычку к связыванию cookie-данных к IP.