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

Question

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

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

Answer 1

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

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

Answer 2

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

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

Answer 3

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

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

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

Answer 4

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

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

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

Express-Brute является отличным примером, который использует кэширование Redis для фильтрации вредоносных запросов и разрешения честных.

Answer 5

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

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

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

Answer 6

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

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

Answer 7

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

Answer 8

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

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

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

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