Лучший способ ограничить (и записать) попытки входа в систему

Question

Очевидно, что какой-то механизм ограничения попыток входа в систему является необходимым условием безопасности.Хотя мне нравится концепция экспоненциального увеличения времени между попытками, я не уверен в сохранении информации.Меня также интересуют альтернативные решения, желательно без капч.

Я предполагаю, что файл cookie не будет работать из-за блокировки файлов cookie или их автоматического удаления, но будут ли сеансы работать?Или его нужно хранить в базе данных?Не зная, какие методы могут/используются, я просто не знаю, какие из них практичны.

Answer 1

Используйте несколько столбцов в таблице пользователей «failed_login_attempts» и «failed_login_time».Первый увеличивается при неудачном входе в систему и сбрасывается при успешном входе в систему.Второй позволяет сравнить текущее время с последним неудачным временем.

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

Answer 2

Предполагая, что Google провел необходимое тестирование удобства использования (не несправедливое предположение) и решил использовать капчу, я бы предложил согласиться с ними.

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

Answer 3

Хранение попыток в базе данных, по моему мнению, является лучшим решением, поскольку оно дает вам записи аудита попыток взлома безопасности.В зависимости от вашего приложения это может быть или не быть юридическим требованием.

Записывая все неудачные попытки, вы также можете собрать информацию более высокого уровня, например, поступают ли запросы с одного IP-адреса (т. е.кто-то/вещь пытается атаковать методом перебора), чтобы вы могли заблокировать IP-адрес.Это может быть ОЧЕНЬ полезная информация.

После того, как вы определили порог, почему бы не заставить их запросить отправку электронного письма на их адрес электронной почты (т. е.аналогично «Я забыл свой пароль»), или вы можете использовать подход CAPCHA.

Answer 4

Политика локаута — это хорошо, но есть баланс.

Одним из соображений является размышление о создании имен пользователей – можно ли их угадать?Можно ли их вообще перечислить?

Я проходил внешний тест на проникновение приложений для доткома с порталом для сотрудников, который обслуживал службы Outlook Web Access/Intranet и некоторые приложения.Было легко подсчитать пользователей (команду руководителей и менеджеров на самом веб-сайте, а также через Google, Facebook, LinkedIn и т. д.).Как только вы получили формат имени пользователя для входа (имя, затем фамилия, введенные в виде одной строки), у меня появилась возможность отключить сотни пользователей из-за их политики «3 удара и выхода».

Answer 5

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

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

Альтернативный (или дополнительный) уровень безопасности должен быть реализован ранее в цикле запросов/разрешений, чтобы защитить приложение и базу данных от выполнения операций блокировки, которые могут быть дорогостоящими и ненужными.

Экспресс-Брют — отличный пример использования кэширования Redis для фильтрации вредоносных запросов и разрешения честных.

Answer 6

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

Мне нравится концепция экспоненциально увеличивающегося времени между попытками, [...]

Вместо использования экспоненциально увеличивающегося времени вы можете фактически иметь случайную задержку между последовательными попытками.

Возможно, если вы объясните, какую технологию вы используете, люди здесь смогут помочь более конкретными примерами.

Answer 7

Храните информацию на стороне сервера.Это позволит вам также защититься от распределенных атак (исходящих с нескольких компьютеров).

Answer 8

Вы можете сказать, что заблокируйте вход в систему на некоторое время, например, через 10 минут после 3 неудачных попыток.Мне кажется, что экспоненциальное увеличение времени звучит хорошо.И да, храните информацию в сеансе на стороне сервера или в базе данных.База данных лучше.Никаких файлов cookie, поскольку ими легко манипулировать пользователем.

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