Должны ли мы запрещать общие пароли, такие как «пароль» и «12345»?
Исследования показывают, что люди могут использовать некоторые действительно «небезопасные» пароли. Вот Например, Mashables - это самое плохое 25 паролей 2011 года . Чтобы защитить безопасность на наших сайтах (и общий опыт работы с менее взломанным сайтом), можем ли мы разумно запретить общие пароли, например, появляться в этом списке? Или, если пользователи, которые хотят использовать «qwerty» в качестве пароля, будут недопустимы, чтобы этого не стоило?
Рассмотрим эти два тематических исследования и ответьте на оба:
-
личная безопасность - сайт сохраняет личную информацию, такую как имя, дата рождения и адрес электронной почты (достаточно, чтобы спам, фиш и беспорядок с кредитами пользователей)
-
финансовая безопасность - сайт сохраняет финансовую информацию, такую как номер кредитной карты (достаточно, чтобы ограбить пользователей и полностью дискредитировать веб-сайт)
Любые исследования по требованиям к паролю, удобству использования и опыту пользователей будут отличными.
4 ответа
Я не думаю, что есть что-то неправильное, если вы не разрешаете эти общие пароли, я просто не буду рекламировать, что вы это сделаете, если это веб-приложение, так как потенциальный взломщик будет учитывать эти правила при попытке взломать учетные записи .
Что вы найдете, так это то, что независимо от правил, которые вы пытаетесь ввести в действие, пользователи, которым не нужна информация, защищающая их пароль, попытаются найти самый простой способ обойти эти правила. Если вы сделаете так, чтобы они не могли использовать p @ ssword, они будут использовать p @ ssword1. Рассмотрим эту статью доктора Рика Смита, озаглавленную «Дилемма пароля» . Основными разделами, которые следует прочитать там для этого вопроса, будут первые три: «Сильные пароли», «Пароли и юзабилити», «Словарь-атаки и сила пароля».
Мое мнение таково, что большинство людей будут рассматривать финансовую информацию, которая должна быть более безопасной, и поэтому пользователь будет более инвестировать в создание надежного пароля. Тем не менее, попытка помочь пользователю сделать свой пароль более сильным, предоставив соответствующее подталкивание /давление, чтобы сделать его более безопасным, также не является плохим соображением.
Я думаю, что наиболее распространенная практика, помогающая продвигать более сильные пароли, - это обеспечить слабый - средний - сильный индикатор для «силы» пароля. Это позволит вам обучать своих пользователей, а не применять строгие правила, которые затем могут быть изучены крекеры для сужения поиска. Эта концепция счетчика - это произвольная мера, призванная заставить пользователя задуматься о выборе пароля. В этой статье приведен пример методологии внедрения измерителя прочности пароля «Адаптивные измерители прочности пароля» от марковских моделей ".
Есть отличная информация об удобстве использования паролей на baekdal.com , в частности о том, наиболее типично трещины.
Существует множество исследований, статей, сообщений и т. д. по вопросу о силе пароля и удобстве использования. Учитывая все вышеизложенное, я лично не нашел ничего, что конкретно указывало на список общих паролей.
Сначала запрет простых паролей звучит как хорошая идея. Хотя, когда вы смотрите на методы реализации, никто не выглядит хорошо:
-
Серверная сторона: человек заполняет & отправляет регистрационную форму, затем получает сообщение об ошибке при перезагрузке. Пробует другой простой пароль и получает другое сообщение об ошибке при перезагрузке. Даже если вы предоставите им список запрещенных паролей, такой опыт довольно расстраивает.
-
Клиентская сторона (JS, загруженная со страницы) : пользователь заполняет поле пароля & получает уведомление о размытии в режиме реального времени. Он может попробовать другой простой пароль или просто добавить простого персонажа в конце, чтобы «закрыть его». В конце концов проблема с паролем не решена.
Вместо этого вы должны показать своим пользователям, что их пароли слабы с помощью счетчика паролей, который является проверенным методом повышения надежности пароля. Недавняя статья Включение выбора пароля пользователя через одноранговое давление ( Декабрь 2011 г.) исследовали, будут ли индикаторы давления сверстников (например, «ваш пароль слабее X% пользователей») более эффективны, чем счетчики паролей. Результаты были неубедительными между двумя методами влияния на силу пароля, но оба метода показали статистически значимое улучшение по сравнению с отсутствием индикаторов (см. Раздел 4, начиная со стр. 39 отчета - (стр. 52 фактического PDF)).
В терминах специальных счетчиков паролей Dropbox zxcvbn (GitHub). Он основан на сложных вычислениях энтропии, которые подробно описаны в их техническом блоге и знаменитом комиксе xckd о правильном штанге батареи для лошади .
Если вы пытаетесь предотвратить базовое «ручное» злоупотребление, то есть Джон сидит за своим столом и пытается войти в аккаунт Алисы, угадывая свой пароль, - тогда непременно пойти дальше и запретить верхнюю 25. Если вы «пытаясь защитить от более серьезных попыток взлома, не поддайтесь никаким иллюзиям, что это что-то достигнет. Атака по словарю не различает никаких двух паролей с одним словом, а для большинства - стандартную замену букв i на обертывание цифрой 1. Если вы действительно хотите, чтобы ваши пользователи получили одолжение, установите разумную минимальную длину (не менее 14 символов) и не , чтобы обеспечить максимальный уровень. Нет причин для обеспечения максимальной длины пароля (кроме того, что можно разумно передать по сети), поскольку пароли должны быть в одностороннем порядке зашифрованы до того, как они будут сохранены.
По умолчанию я бы не запретил общие пароли, но я бы поставил индикатор силы, чтобы дать пользователям четкую обратную связь о том, как «безопасный» является их паролем. Имейте в виду, что пароль является личным выбором, и если вы не разъясняете им, пользователи имеют право выбрать любой пароль.
Сказали, что вы должны понимать, что это не только вопрос UX, но и вопрос IA. Зачем вам пароль? Какую информацию этот пароль позволит пользователям получить доступ? У вас есть иерархия пользователей? Кто может получить доступ к конфиденциальной информации? И так далее. После того, как вы это поняли, вы можете принять решение о том, как обрабатывать пароли пользователей.