Реализация проверки скорости входа

Question

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

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

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

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

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

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

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

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

Answer 1

В конце концов я построил нечто похожее на то, что предложил Джон Бокер. Таблица, используемая для аутентификации пользователей, имеет два новых столбца - 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. Если это значение превышает максимально допустимую скорость, проверка скорости не выполняется.

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

Answer 2

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

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

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

Answer 3

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