Я видел веб-приложения с ограничениями для попыток входа пользователя.
Это необходимость безопасности, и если да, то почему?
Например: у вас было три неудачных попытки входа в систему, давайте попробуем снова через 10 минут!
Разъяснение Это завершение других ответов. Используя хорошо реализованный капчу, наряду с механизмом борьбы с грубой силой, используя сеансы, например.
Вопроситель отметил это как принятое, предполагая, что captchas не читаются машинами (она почти права), и поэтому она получает отрицательные моменты, потому что люди думают, что это не полный ответ, и они правы.
Также использование хорошо реализованного CAPTCHA может быть альтернативным способом обеспечения безопасности приложений для атаки грубой силы. есть широкий выбор провайдеров captcha, доступных бесплатно, давайте попробуем простой способ, если вы спешите. Также, пожалуйста, подумайте, что здесь есть люди, говорящие, что «о, нет! Эта вещь капчей не достаточно безопасна, и они правы иногда!» ,
«Для тех из вас, кто не знает, CAPTCHA – это программа, которая может определить, является ли ее пользователь человеком или другим компьютером. Это те маленькие изображения искаженного текста, которые вы переводите, когда вы подписываетесь на Gmail или оставляете комментарий на чей-то блог. Их цель – убедиться, что кто-то не использует компьютер, чтобы автоматически регистрировать миллионы онлайн-аккаунтов или … ».
Я видел творческий подход к этому однажды …
Для каждой попытки входа в систему это не работает, время блокировки увеличивается … экспоненциально.
attempt | lockout time ====================== 1 | 2s 2 | 4s 3 | 8s 4 | 16s 5 | 32s 6 | 64s 7 | 128s 8 | 256s 9 | 512s 10 | 1024s Теоретически, это позволяет пользователю совершить ошибку или два, но, как только она становится попыткой взлома, хакер блокируется в течение более длительных и длительных периодов времени.
Я не использовал это сам (пока), но концептуально мне очень нравится идея. Конечно, при успешном входе в систему счетчик сбрасывается.
Ограничение того, сколько попыток сделать на веб-сайте, – это предотвращение нападений с грубой силой (автоматическим) на ваш сайт. Если вы не ограничите эти попытки, хакер может настроить сценарий, чтобы угадывать пароли до тех пор, пока он не найдет его, и это может повлиять на доступность вашего веб-сервера.
Как правило, вы можете захотеть вытащить пользователя (10 минут, как вы упомянули), после трех попыток, и заблокировать их после 6 или 9 последовательных повторных попыток, заставляя пользователя связаться с вами, чтобы разблокировать их учетную запись. Это введено в действие, потому что кто-то может изменить свои сценарии, чтобы настроить таймаут.
Если пользователи могут устанавливать свои собственные пароли, некоторые боты / малыша будут пытаться войти в систему со списком общих паролей и добиться успеха. И если они не знают пользователей, они будут пытаться использовать общие имена, такие как admin, simon, rico и т. Д.
Это не помогает просто помечать пользователя в сеансе, поскольку они могут просто удалить куки-файл или параметр запроса на их конце. Вы должны иметь счет неудачных попыток входа в систему как для IP, так и для имени входа. Возможно, вам будет легче простить IP-адрес, поскольку он может использоваться многими пользователями.
Для моих собственных проектов я написал обобщенную библиотеку «floodcontrol», которая обрабатывает подобные вещи.
Это позволяет мне указать, сколько попыток может быть сделано за X промежуток времени. Он допускает определенное количество попыток «благодати» за короткое время, так что будет обнаружено только действительно необычное поведение.
Я записываю в базу данных несколько вещей:
Для каждой попытки я делаю запрос против частичного IP-адреса и действия, и если предыдущая попытка была сделана в течение определенного времени времени, я увеличиваю счетчик попыток для этой попытки. Если счетчик попыток превысит количество попыток изящества, то я проверю, была ли последняя попытка в течение X секунд, и если да, верните false – поэтому действие будет заблокировано (и пользователю будет предложено подождать X секунд, прежде чем пытаться еще раз). Если счетчик попыток ниже числа попыток изящества, я возвращаю true и позволяю ему сползать.
Если человек с тем же IP-адресом приходит позже, тогда предыдущий счетчик попыток не будет получен, потому что он будет слишком давно.
Да, необходимо защитить учетные записи от сложных атак с использованием грубой силы – как в случае использования ботов и файлов словарей – до тех, кто просто пытается угадать пароль учетной записи.
Я считаю, что положить счетчик неудачных попыток в БД был бы самым безопасным и простым способом. Таким образом, пользователь не может обойти его (отключив файлы cookie). Сброс при успешном входе в курс обучения.
Сброс неудачных попыток после правильного входа почти делает всю систему бесполезной.
Любой зарегистрированный пользователь может затем сделать три догадки на чужой учетной записи и пароль, а затем войти в систему со своим собственным, чтобы сбросить счетчик, и повторить – это также может быть автоматизировано. Таким образом, обычный зарегистрированный пользователь может, например, использовать пароли администратора.
Сброс необходимо выполнить администратору, а не просто войти в систему успешно.