Внедрение проверок скорости входа в систему

Мне нужно реализовать проверку скорости входа в систему для веб-службы. Сервис находится на рубине, а база данных — MySql.

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

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

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

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

Мой вопрос к Stack Overflow: как обычно в промышленности реализуются проверки скорости входа в систему?

Обновление 1:

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


person itfische    schedule 06.05.2009    source источник


Ответы (3)


В конце концов я построил что-то похожее на то, что предложил Джон Бокер. Таблица, используемая для аутентификации пользователей, имеет два новых столбца — failed_login_count и first_failed_login, которые являются объектом DateTime. Каждый раз, когда пользователь успешно входит в систему, failed_login_count сбрасывается на 0, а first_failed_login сбрасывается на null, если это еще не было сделано. Каждый раз, когда происходит неудачная попытка входа в систему, failed_login_count увеличивается. Если это было 0, first_failed_login получает текущее время. Каждый раз, когда пользователь пытается войти в систему, перед проверкой пароля происходит проверка скорости. Если failed_login_count больше 0, оно делится на разницу во времени между текущим временем и first_failed_login. Если это значение превышает максимально допустимую скорость, проверка скорости завершается неудачно.

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

person itfische    schedule 07.05.2009

Я считаю, что в поставщике членства по умолчанию asp.net есть столбец в одной из пользовательских таблиц с именем FailedPasswordAttemptCount, я уверен, что он просто увеличивается для каждой неудачной попытки, а затем сбрасывается до 0 в случае успеха. С помощью этого столбца и столбца LastLoginAttemptTimestamp вы можете заблокировать пользователей на определенное время.

person John Boker    schedule 06.05.2009
comment
Спасибо за ответ. Это явно работает, но фактически не выполняет проверку скорости. Я должен был определить это в вопросе - алгоритмы, которые мы будем использовать, связаны с количеством сбоев за временной интервал. Возможно, если бы мы также сохранили отметку времени для первой неудачной попытки входа в систему, это сделало бы это решение эквивалентным. - person itfische; 07.05.2009

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

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

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

person James C    schedule 06.05.2009