Почему бы не использовать сеансы вместо базы данных для блокировки учетной записи
Я создаю веб-приложение и исследовал вопрос о блокировке аккаунта как о способе противодействия грубым атакам. В поисках лучшего способа реализовать это привело меня к следующим ссылкам
2. PHP блокировка пользователя после 3 неудачных входов в систему в течение 10 минут
3. Блокировка доступа к странице входа после трех неудачных попыток входа
4. Как заблокировать пользователя после 3 неудачной подачи неверной информации
Есть еще много ссылок, но все они сказали то же самое:
1. Create Database
2. Store Login Attempt Details
3. Add 1 to number of attempts
4. Set timed session if No of attempts > 3/5
Это, однако, заставило меня задуматься, почему описанный ниже метод не лучше или хотя бы одинаково хорош?
1. Set a session "[No of login attempts]" on failed login
2. Add "1" to "[No of login attempts]" on each failed login
3. Proceed with account lockout if "Session[No of login attempts]" is greater than 3/5
У меня такое ощущение, что это лучше из-за простоты. Метод базы данных добавляет к ненужным накладным расходам и задачам по управлению таблицей (может потребоваться удалить данные неудачного входа в систему из прошлого или разрешения входа в систему и т. Д.)
Но я не вижу никого, кто бы рекомендовал этот метод
Что мне здесь не хватает?
Решение
Пара вещей:
- Тайм-аут сессий. Если ваш злоумышленник просто ждет достаточно долго, подсчет его неудач будет забыт.
- Сессии могут быть привязаны к куки. В этом случае, если злоумышленник очистит свои куки, он получит новый идентификатор сеанса и новый набор счетчиков. Если злоумышленник выяснит вашу схему файлов cookie, он может даже создать свои собственные файлы cookie и получить столько сеансов, сколько пожелает.
- Сеансы также можно отслеживать по параметрам URL-адресов. В этом случае повторная попытка с базовым URL сбросит попытки входа в систему. Кроме того, как и в случае файлов cookie, если злоумышленник может определить вашу схему идентификатора сеанса, он может создать большое их количество.
Другие решения
Других решений пока нет …
detector