В журнале неудачных попыток входа выставлены пароли

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

Failed login attempt by qntmfred

Я заметил, что некоторые из этих журналов выглядят как

Failed login attempt by qntmfredmypassword

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

Есть ли лучший способ справиться с этим? Должен ли я даже беспокоиться об этой возможности?

Попробуйте это так:

Если имя пользователя существует, запишите «неудачная попытка входа в систему username». Если нет, запишите «неудачная попытка входа по IP 123.45.67.89». Это должно решить проблему случайного появления паролей в журнале.

Почему бы просто не проверить, существует ли такое имя пользователя в базе данных? Это даст вам 2 возможных результата.

1. Пользователь ввел правильное имя пользователя. Тогда вы можете просто войти в то, что вы входите сейчас

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

И, конечно, у вас может быть дополнительное поле для регистрации IP, даты и что нет?

Соображения:

1. Можете ли вы определить, когда это произошло, в отличие от того, кто неправильно набирает имя пользователя? Регистрация неправильных имен пользователей может быть полезна в целях поддержки, т.е. для ответа на вопрос «почему я не могу войти в систему» ​​с ответом «Вы неправильно набрали имя пользователя, которое должно быть тире, а не точкой», или «У вас двоеточие» затем пробел - вы вырезали и вставили его ". Если у вас есть небольшое количество высокооплачиваемых пользователей (то есть, еще не один сайт социальной сети), вам, вероятно, придется предоставить такую ​​поддержку.

2. Какое действие следует предпринять кому-то? Имена пользователей могут быть индикаторами попыток взлома. Тот факт, что имя пользователя не появляется в вашем списке, не означает, что вам не нужно знать, что это было. Однако, если вы считаете, что это серьезная проблема, и вы можете определить, чей это был пароль, вы можете потребовать, чтобы пользователь изменил свой пароль после того, как это произошло.

3. Что такое отраслевая практика? Промышленная практика заключается в регистрации поля имени пользователя, но не поля пароля. Вас вряд ли уволят за это.

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

На всякий случай, регистрация в моем текущем приложении не хранит параметры, переданные в методы входа в систему или сброса пароля. В вызове журнала есть необязательный параметр, который управляет этим, и при значении true объект хранимых параметров заменяется на [Redacted]. Конечно, поэтому я пропускаю немного данных, но у меня есть их IP-адреса, и я бы предпочел не рисковать, чтобы получить что-то, что чувствительно в открытом тексте.

Если вы действительно хотите регистрировать подобные вещи, я бы посоветовал, чтобы при регистрации попытки входа в систему вы проверяли базу данных на наличие пользователей с именем, совпадающим с тем, которое у вас есть в поле имени пользователя, и сохраняли его только при наличии совпадения. В противном случае вы просто сохраняете его как «неизвестный пользователь». Вы можете подумать, проверив, содержит ли это значение то или иное, но всегда есть риск, что вы получите комбинации, такие как [User] [Password] и [UserPas] [sword], и в этом случае вы можете проверить по IP и вывести, что Вы случайно сохранили начало чьего-либо пароля в открытом виде. Вы можете распространить это на маловероятные, но возможные [User] [Password] и [UserPassword] [??], и в этом случае вы можете увидеть «неудачный вход в систему с помощью UserPassword», за которым следует «Успешный вход в систему пользователем» и вывести всепароля пользователя. Как правило, для безопасности я бы сказал, чтобы не регистрировать имена пользователей, если вход в систему не будет успешным.

Изменить, чтобы добавить:

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

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

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