Дизайн базы данных для записи неудачных попыток входа в систему для предотвращения грубого принуждения

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

Подход 1) Создайте таблицу, которая будет записывать: IP-адрес, имя пользователя и время попытки. Затем, когда пользователь пытается войти в систему, я запускаю команду select, чтобы определить, сколько раз имя пользователя было испробовано за последние 5 минут (или сколько раз пытались использовать конкретный IP-адрес за последние 5 минут). Если значение превышает определенное значение, либо ограничьте количество попыток входа в систему, либо отобразите капчу.

Это позволяет регулировать как по имени пользователя, так и по IP-адресу (если атака пытается использовать несколько разных имен пользователей с одним паролем) и создает легко проверяемую запись о том, что произошло, но требует INSERT для каждой попытки входа в систему и как минимум одного дополнительного ВЫБРАТЬ.

Подход 2) Создайте аналогичную таблицу, в которой записывается количество неудачных попыток и время последнего входа в систему. Это может привести к уменьшению размера таблицы базы данных и более быстрому оператору SELECT (COUNT не требуется), но предлагает немного меньше контроля, а также меньше данных для анализа.

Подход 3) Аналогичен подходу 2, но сохраняет эту информацию в самой таблице User. Это означает, что дополнительный оператор SELECT не потребуется, хотя он добавит дополнительную, возможно, ненужную информацию в таблицу пользователей. Это также не позволило бы получить дополнительный контроль и информацию, которые предлагает подход 1.

Дополнительные подходы: сохраните попытки входа в систему в таблице MEMORY mysql или таблице sqlite в памяти. Это снизит потерю производительности из-за производительности диска, но по-прежнему требует вызовов базы данных и не позволит длительный аудит попыток входа в систему, поскольку данные не будут постоянными.

Есть мысли о том, как это сделать, или о том, что реализовали вы сами?


person travis-146    schedule 28.07.2009    source источник
comment
Могу ли я сказать привязать имя пользователя к IP, чтобы вы не блокировали действительного пользователя, потому что кто-то другой пытается подобрать учетную запись?   -  person Meep3D    schedule 28.07.2009
comment
Что делать, если у вас несколько пользователей с одного IP-адреса?   -  person nilamo    schedule 28.07.2009
comment
Meep3D: это хороший момент, который зависит от необходимого уровня безопасности. Использование капчи вместо блокировки решило бы проблему DOSing. nilamo: очевидно, что количество недействительных входов с этого IP-адреса должно быть достаточно высоким, но при определенном количестве неверных входов в систему за короткий промежуток времени капча кажется разумной.   -  person travis-146    schedule 28.07.2009


Ответы (2)


Похоже, вы преждевременно оптимизируете.

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

Я ожидал, что подход №1 будет наиболее естественным решением.

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

person Kieveli    schedule 28.07.2009

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

  • Отметьте время злоупотребления
  • Прекратить считать (и, таким образом, прекратить вставку / обновление)
  • Заблокируйте ip на несколько часов.

Этот порог должен быть намного выше, чем тот, который ограничивает / вводит капчу.

person Draemon    schedule 28.07.2009