Наказание пользователей за небезопасные пароли [закрыто]

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

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

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

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

ЯГНИ , ПОЦЕЛУЙ , СУХОЙ , правило 10 секунд и тот факт, что «вы не заботитесь о ВАС», вероятно, должны сузить его до одного решения: не надо.

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

Либо принудительно установите безопасный пароль при изменении регистрации, либо используйте OpenId (2c Джеффа Этвуда: http://www.codinghorror.com/blog/2010/11/your-internet-drivers-license.html ). Тогда сконцентрируйтесь на более интересной функциональности.

С одной стороны, пользователи привыкли создавать безопасные пароли или использовать свой OpenId, поэтому для них это просто.

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

Мой ответ просто сводится к KISS .

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

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

Лучшее решение: улыбающиеся лица.

Я серьезно! Чтение книг по поведенческой экономике, таких как «подталкивание: улучшение решений о здоровье, богатстве и счастье», убедило меня в нескольких вещах:

1. Вы не можете заставить всех принять мудрые решения.
2. Людям нравится быть свободными в выборе, но им не нравится много вариантов.
3. Вы можете, однако, значительно повлиять на их выбор в лучшую сторону с помощью простых приемов.

Я вижу, что эти принципы применимы к вашей ситуации следующим образом:

1. Ограничение пользователей на основе небезопасных паролей, скорее всего, расстроит и запутает их ... особенно для большинства людей, которые не читают тщательно написанные объяснения в диалоговых окнах и просто звонят в службу поддержки, чтобы сказать: «Это не Работа."
2. При создании паролей пользователям не нужно видеть список всех возможностей специальных символов и таких, которые они могут использовать. Лучше показать им немного всплывающих окон, предлагающих добавить некоторую сложность, только если их запись не соответствует требованиям.
3. На людей сильное влияние оказывают социальные сигналы - даже такие маленькие, как счастливые лица, показывающие, что мы одобряем их поведение, или хмурые лица, если мы этого не делаем. На некоторых веб-сайтах с лучшим дизайном будет отображаться цветная полоса прогресса, которая изменится с красного на « Не достаточно хорошо» :( на зеленый для « Хорошо»! :), когда пользователь вводит свой (предлагаемый) пароль и подтверждение. Этот пользовательский интерфейс дает им некоторое социальное давление для того, чтобы соответствовать стандартам - заставить планку загореться зеленым или сменить хмурый взгляд на улыбку - поскольку они сами обнаруживают, как создавать более безопасные пароли с помощью немедленной обратной связи от цвет меняется.

Не в кучу, но я подумал о другой причине подать это под «Плохая идея», о которой я еще не упоминал, - о поддержке клиентов.

Если это продукт, за которым стоят представители службы поддержки, им это не очень понравится. Одно из основных предположений службы поддержки заключается в том, что они понимают и могут предсказать взаимодействие с пользователем - если они помогают обычному пользователю, то на странице 1 должны быть ссылки на страницы 2, 3 и 4, где они могут выполнять X, Y, Z , и т.д.

Теперь вы даете им другую переменную, которую они должны отслеживать. Если пользователь не видит ссылку на страницу 4, это потому, что он сделал что-то глупое? Или это потому, что их пароль отстой, а ваша система наказывает их, отказывая им в доступе к странице 4? Подождите ... дерьмо, отказ в доступе к одному из наказаний за неправильный пароль, или я думаю о странице 5? Позвольте мне взглянуть на это, только один момент ... хорошо, он говорит, что для пароля, который не смешивает прописные и строчные буквы, доступ к четным страницам разрешен, но ограничен только для чтения ... хорошо, Сэр, ваш пароль, он состоит из всех заглавных или строчных букв? Случай. Когда вы просто набираете букву, это строчные буквы; когда вы используете shift, это когда это верхний регистр. Вы смешали дела в своем пароле? Пароль, который вы использовали для входа в систему. Тот, который вы только что использовали. Хорошо, перейдите в Edit, затем выберите Preferences, затем Security. Выберите «Сохраненные пароли» ... нет, сэр, я не вижу ваши пароли отсюда ....

Да. Не делай этого.

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

и может ли он быть расположен в радужном столе

Я предполагаю, что вы имеете в виду словарь, а не радужный стол. Атака по словарю работает только на тестирование всех слов словаря, если они соответствуют паролю. Эту атаку можно исправить 5-ю попытками и блокировать на х минут ...

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

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

На время хеширования: подумайте о времени ожидания 500 мс для механизма входа в систему. Я думаю, что это приемлемо ... (напоминание: почти одна секунда требует рукопожатия для SSL)