Ограничение попыток входа пользователя в PHP

Question

Я видел веб-приложения с ограничениями для попыток входа пользователя.

Это необходимость в безопасности и, если да, то почему?

Например: у вас было три неудачных попытки входа, давайте попробуем еще раз через 10 минут !!

Answer 1

Я видел творческий подход к этому однажды ...

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

attempt | lockout time
======================
   1    |     2s
   2    |     4s
   3    |     8s
   4    |    16s
   5    |    32s
   6    |    64s
   7    |   128s
   8    |   256s
   9    |   512s
  10    |  1024s

Теоретически, он позволяет пользователю совершить одну или две ошибки, но как только это становится «хакерской» попыткой, хакер блокируется на все более длительные периоды времени.

Я не использовал это сам (пока), но концептуально мне очень нравится эта идея. Конечно, при успешном входе в систему счетчик сбрасывается.

Answer 2

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

"Для тех из вас, кто не знает, CAPTCHA - это программа, которая может определить, является ли ее пользователь человеком или другим компьютером. Это маленькие картинки искаженного текста, которые вы переводите, когда Вы подписываетесь на Gmail или оставляете комментарий в чьем-либо блоге. Их цель - убедиться, что кто-то не использует компьютер для автоматической подписки на миллионы учетных записей в Интернете, или .. " ref .

Answer 3

Если пользователи могут установить свои собственные пароли, некоторые бот / ребенок попытаются войти в систему со списком общих паролей, и это удастся. И если они не знают пользователей, они будут использовать общие имена, такие как admin, simon, rico и т. Д.

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

Answer 4

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

Как правило, вы можете захотеть отключить пользователя (10 минут, как вы упомянули) после 3 попыток и заблокировать его после 6 или 9 последовательных повторных попыток, заставляя пользователя связаться с вами, чтобы разблокировать свою учетную запись. Это сделано для того, чтобы кто-то мог изменить свои сценарии, чтобы скорректировать ваше время ожидания.

Answer 5

Для своих собственных проектов я написал обобщенную библиотеку 'floodcontrol', которая обрабатывает подобные вещи.

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

Я записываю в базу данных несколько вещей:

• IP-адрес (или его первые 24 бита)
• Действие, которое было предпринято (т. Е. «Войти в систему», «поиск», «комментарий»)
• Время покушения
• Количество попыток (счетчик попыток)

Для каждой сделанной попытки я запрашиваю частичный IP-адрес и действие, и если предыдущая попытка была сделана в течение определенного периода времени, то я увеличиваю счетчик попыток для этой попытки. Если счетчик попыток превышает количество разрешенных попыток отсрочки, я проверяю, была ли последняя попытка в течение X секунд, и если да, возвращает false - следовательно, действие будет заблокировано (и пользователю будет предложено подождать X секунд перед попыткой снова). Если счетчик попыток меньше числа попыток отсрочки, я возвращаю значение true и позволяю ему скользить.

Если человек с таким же IP-адресом приходит позже, то счетчик предыдущих попыток не будет получен, потому что он будет слишком давно.

Answer 6

Сброс неудачных попыток после правильного входа почти делает всю систему бесполезной.

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

Сброс должен выполняться администратором, а не простым успешным входом.

Answer 7

Я считаю, что установка счетчика «неудачных попыток» в БД была бы самым безопасным и простым способом. Таким образом, пользователь не может обойти это (отключив куки). Сбросить при успешном входе конечно.

Answer 8

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