Очевидно, что какой-то механизм ограничения попыток входа в систему является необходимым условием безопасности. Хотя мне нравится концепция экспоненциально возрастающего времени между попытками, я не уверен в сохранении информации. Меня также интересуют альтернативные решения, предпочтительно не включая captchas.
Я предполагаю, что cookie не будет работать из-за блокировки файлов cookie или очистки их автоматически, но будут ли сеансы работать? Или он должен храниться в базе данных? Не зная, какие методы могут/используются, поэтому я просто не знаю, что практично.
Используйте несколько столбцов в таблице ваших пользователей "failed_login_attempts" и "failed_login_time". Первая добавляет к неудачному входе в систему и сбрасывается при успешном входе в систему. Второй способ позволяет сравнить текущее время с последним неудачным временем.
Ваш код может использовать эти данные в db, чтобы определить, как долго он будет блокировать пользователей, время между допустимыми входами и т.д.
Предполагая, что Google выполнил необходимое тестирование юзабилити (не несправедливое предположение) и решил использовать captchas, я бы предложил пойти с ними.
Увеличение тайм-аутов разочаровывает, когда я являюсь подлинным пользователем и забыл свой пароль (с таким количеством сайтов и связанных с ними паролей, которые случаются очень часто, особенно для меня)
Сохранение попыток в базе данных является лучшим решением IMHO, поскольку оно дает вам аудиторские записи о попытках нарушения безопасности. В зависимости от вашей заявки это может быть или не быть юридическим требованием.
Записывая все неудачные попытки, вы также можете собирать информацию более высокого уровня, например, если запросы поступают с одного IP-адреса (т.е. кто-то/пытается атаковать грубую силу), поэтому вы можете заблокировать IP-адрес. Это может быть ОЧЕНЬ полезная информация.
Как только вы определили пороговое значение, почему бы не заставить их запросить отправку электронного письма на свой адрес электронной почты (например, аналогично "Я забыл свой пароль" ), или вы можете пойти на подход CAPCHA.
Политика блокировки - все хорошо и хорошо, но есть баланс.
Одно соображение - подумать об уничтожении имен пользователей - допустимо? Могут ли они быть перечислены вообще?
Я был на внешнем испытании Pen Pen для dotcom с Employee Portal, который обслуживал службы Outlook Web Access/Intranet Services, определенные приложения. Было легко перечислить пользователей (команда Exec/Managament на самом веб-сайте, а также через Google, Facebook, LinkedIn и т.д.). После того, как вы получили формат входа в систему с именем пользователя (имя и фамилия, введенные как одна строка), у меня была возможность закрыть 100 пользователей из-за их трех ударов и политики.
Вы знаете, какой идентификатор пользователя попал, сохраните флаг и, когда он достиг порогового значения, просто прекратите принимать что-либо для этого пользователя. Но это означает, что вы сохраняете дополнительное значение данных для каждого пользователя.
Мне нравится понятие экспоненциально возрастающего времени между попытками, [...]
Вместо использования экспоненциально возрастающего времени у вас может быть рандомизированное отставание между последовательными попытками.
Возможно, если вы объясните, какие технологии вы используете, люди здесь смогут помочь с более конкретными примерами.
Храните информацию на стороне сервера. Это позволит вам также защищаться от распределенных атак (исходящих от нескольких машин).
Возможно, вам захочется сказать, что блокирование логина в течение некоторого времени говорит, например, через 10 минут после трех попыток сбоя. Мне кажется, что время экспоненциально возрастает. И да, сохраните информацию на сеансе или базе данных на стороне сервера. База данных лучше. Нет куки-бизнеса, поскольку пользователь легко манипулирует ими.
Возможно, вы также захотите сопоставить такие попытки с IP-адресом клиента, поскольку вполне возможно, что действительный пользователь может получить заблокированное сообщение, в то время как кто-то пытается угадать действительный пароль пользователя с попытками сбоев.
Ответы в этом сообщении определяют приоритеты централизованной базы данных, поскольку они обеспечивают структуру записей, которые делают логику аудита и блокировки удобной.
В то время как ответы здесь касаются угадывания атак на отдельных пользователей, основная проблема с этим подходом заключается в том, что он оставляет систему открытой Отказ в обслуживании атак. Любые запросы из мира должны не работать с базой данных.
Альтернативный (или дополнительный) уровень безопасности должен быть реализован ранее в цикле req/res, чтобы защитить приложение и базу данных от выполнения операций блокировки, которые могут быть дорогими и не нужны.
Express-Brute - отличный пример, который использует кэширование Redis для фильтрации вредоносных запросов, позволяя честным.