Регулирование попыток входа в систему

Question

(Это принципиально не зависящий от языка вопрос, хотя в моем случае я использую ASP.NET 3.5)

Я использую стандартный ASP.NET элемент управления входом и хотел бы реализовать следующую неудачную логику регулирования попыток входа в систему.

• Обработка события OnLoginError и ведение, в Сеанс , количества неудачных попыток входа в систему
• Когда этот счетчик достигает [некоторое настраиваемое значение] блокировать дальнейшие попытки входа в систему с исходного IP-адреса или для этого пользователя / этих пользователей на 1 час

Это звучит как разумный подход? Я упускаю очевидный способ обойти такие проверки?

Примечание. Сеанс ASP.NET связан с браузером пользователя с помощью файла cookie

.

Редактировать

Это для административного сайта, который будет использоваться только из Великобритании и Индии.

Answer 1

Последнее, что вы хотите сделать, - это сохранить все неудачные попытки входа в базу данных, это будет работать достаточно хорошо, но при этом DDOS-атакам будет очень тривиально отключить сервер базы данных.

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

Если вы пытаетесь остановить людей от грубой аутентификации, система регулирования, подобная предложенной Гамбо, вероятно, будет работать лучше. Это сделает атаки методом "грубой силы" неинтересными для злоумышленника, в то же время сводя к минимуму воздействие для законных пользователей в обычных условиях или даже во время атаки. Я бы посоветовал просто подсчитать количество неудачных попыток по IP в memcached или подобном, и если вы когда-нибудь станете мишенью для чрезвычайно распределенной атаки методом перебора, вы всегда можете выбрать также отслеживать попытки по имени пользователя, предполагая, что злоумышленники на самом деле часто пытаются использовать одно и то же имя пользователя. До тех пор, пока попытка не очень распространена, так как все еще исходит из исчисляемого количества IP-адресов, исходный код by-IP должен достаточно адекватно удерживать злоумышленников.

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

Еще одно предложение, которое не отвечает на ваш вопрос, но в некоторой степени связано с этим, заключается в обеспечении определенного уровня безопасности пароля для ваших конечных пользователей. Я бы не стал зацикливаться на требовании пароля в смешанном регистре, по крайней мере x символов, не словаря и т. Д. И т. Д., Потому что вы не хотите много глючить, когда они еще даже не зарегистрировались, но простое запрещение людям использовать свое имя пользователя в качестве пароля должно очень долго защищать ваш сервис и пользователей от самых простых атак - угадайте, почему они называют их грубыми атаками;) - атак.

Answer 2

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

1st failed login    no delay
2nd failed login    2 sec delay
3rd failed login    4 sec delay
4th failed login    8 sec delay
5th failed login    16 sec delay

Это уменьшит риск злоупотребления этой мерой защиты для атак отказа в обслуживании.

См. http://www.codinghorror.com/blog/archives/001206.html

Answer 3

Принятый ответ, который добавляет увеличивающиеся задержки в последовательные попытки входа в систему, может очень плохо работать в ASP.NET в зависимости от того, как он реализован. ASP.NET использует пул потоков для обслуживания запросов. Как только этот пул потоков исчерпан, входящие запросы будут помещены в очередь, пока поток не станет доступным.

Если вы вставите задержку с помощью Thread.Sleep (n), вы свяжете поток пула потоков ASP.NET на время задержки. Этот поток больше не будет доступен для выполнения других запросов. В этом случае простая атака в стиле DOS будет продолжать отправлять форму входа в систему. В конце концов каждый поток, доступный для выполнения запросов, будет находиться в спящем режиме (и в течение увеличивающихся периодов времени).

Единственный способ правильно реализовать этот механизм задержки - использовать асинхронный HTTP-обработчик. См. Пошаговое руководство. Создание асинхронного обработчика HTTP . Для реализации, вероятно, потребуется:

1. Попытка аутентификации во время BeginProcessRequest и определение задержки при сбое
2. Возвращает IAsyncResult, выставляющий WaitHandle, который будет запущен после задержки
3. Убедитесь, что WaitHandle был запущен (или заблокирован, пока не был) в EndProcessRequest

Answer 4

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

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

Answer 5

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

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

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

Также монитор для того же IP / другого пользователя и того же пользователя / другого IP.