Ненадежно информировать пользователя, какая часть учетных данных была неверной при сбое входа?

Question

Я ничего не мог придумать в Google, но это вопрос, который у меня в голове был некоторое время, поэтому я решил представить его здесь.

Допустим, вы разрабатываете типичное имя пользователя / пароль для входа. Вы настраиваете форму, в которой пользователь вводит свое имя пользователя и пароль, а затем нажимает кнопку для входа в систему. Теперь, допустим, они неправильно ввели пароль. Лучше ли вообще говорить, что вход в систему не выполнен, или допустимо специально информировать пользователя о том, что его пароль был неправильным?

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

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

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

Спасибо!

Answer 1

Лично я считаю, что говорить пользователю, что аккаунта не существует, - это плохая практика. Взгляните на пример Google (или большинства других крупных поставщиков веб-услуг). Сообщение об ошибке, возвращаемое для неудачного входа в Gmail, выглядит следующим образом: http://support.google.com/accounts/bin/answer.py?hl=en&p=mail&ctx=ch_ServiceLoginAuth&answer=27444

Обратите внимание, что даже если имя пользователя не существует, возвращается точно такая же ошибка . Это не позволяет потенциальному злоумышленнику / спамеру извлекать адреса электронной почты из-за разницы между «Пользователь не найден» и «Сбой имени пользователя / пароля».

Ссылка: http://www.harezmi.com.tr/how-to-keep-hackers-informed-about-your-users/?lang=en

Answer 2

Зависит от характера сайта.Если это приложение для онлайн-банкинга, то ничего не отдайте.

Если это просто вход на форум или комментарий, то сообщение о том, что я использовал неправильное имя пользователя / email / passwd, поможет избежать многих разочарований

Answer 3

Честно говоря, я не понимаю, почему вы не должны говорить пользователю, что пошло не так.Конечно, некоторые из них не согласятся со мной, и если мы потенциально дадим злоумышленнику действительные имена пользователей, это, конечно, будет использовано в атаках с использованием SQL-инъекций и атаках методом "грубой силы", которые могут представлять угрозу безопасности.Но я мотивирую свой ответ этими пунктами.

1. Первый - из вашего собственного вопроса

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

   Это действительно ключ, и если у вас есть такие механизмы, как разрешение только нескольких неудачных попыток для имени пользователя в час, ограниченных неудачных попыток на IP-адрес в часДлинные пароли и т. д. резко снизят шансы злоумышленников взломать пароль, даже если они знают имя пользователя.Если они могут проверять только 10 паролей на имя пользователя и 100 паролей в общей сложности каждый час, потребуется около 285 дней для проверки каждой возможной комбинации 6-символьного пароля ASCII и 1995 дней с 7-символьным паролем.Я знаю, что злоумышленники могут фальсифицировать IP-адреса, поэтому этот конкретный метод сам по себе не является водонепроницаемым, но, возможно, он серьезно затрудняет брутфорсинг, и это моя точка зрения.

2. Общее сообщение об ошибке граничит с безопасностью из-за неизвестности.Скорее всего, злоумышленник уже знает одно или несколько имен пользователей.Т.е. они знают почтовый адрес, и люди часто используют одно и то же имя пользователя, они используют время (как указал Джонатан Леффлер), чтобы определить, могут ли их имена пользователя быть действительными, некоторые имена пользователей действительно распространены (например, admin и administrator) и так далее.Если часть вашей безопасности основана на том факте, что злоумышленник не должен знать / угадывать имена пользователей, вы не будете готовы, когда они узнают.

3. Хранимые процедуры снизят риски атак с использованием SQL-инъекций.и используя основные меры безопасности (не используя URL-адреса, такие как domain.com/delete/user/username/, чтобы действовать и быть бдительным при авторизации), злоумышленник не может сделать ничего с именем пользователя, кроме как попытка подбора.

Таким образом, я считаю, что риск очень низок, а выгоды достаточно высоки для пользователя.Он также рекомендует вам, как разработчику, не лениться с безопасностью.

Answer 4

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

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

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

Answer 5

Я хотел бы получить общее сообщение об ошибке («Ошибка входа с указанным адресом электронной почты / паролем») и функцию сброса рабочего пароля (по электронной почте).