Должны ли мы запрещать общие пароли, такие как «пароль» и «12345»?

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

Что вы найдете, так это то, что независимо от правил, которые вы пытаетесь ввести в действие, пользователи, которым не нужна информация, защищающая их пароль, попытаются найти самый простой способ обойти эти правила. Если вы сделаете так, чтобы они не могли использовать p @ ssword, они будут использовать p @ ssword1. Рассмотрим эту статью доктора Рика Смита, озаглавленную «Дилемма пароля» . Основными разделами, которые следует прочитать там для этого вопроса, будут первые три: «Сильные пароли», «Пароли и юзабилити», «Словарь-атаки и сила пароля».

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

Я думаю, что наиболее распространенная практика, помогающая продвигать более сильные пароли, - это обеспечить слабый - средний - сильный индикатор для «силы» пароля. Это позволит вам обучать своих пользователей, а не применять строгие правила, которые затем могут быть изучены крекеры для сужения поиска. Эта концепция счетчика - это произвольная мера, призванная заставить пользователя задуматься о выборе пароля. В этой статье приведен пример методологии внедрения измерителя прочности пароля «Адаптивные измерители прочности пароля» от марковских моделей ".

Есть отличная информация об удобстве использования паролей на baekdal.com , в частности о том, наиболее типично трещины.

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

Сначала запрет простых паролей звучит как хорошая идея. Хотя, когда вы смотрите на методы реализации, никто не выглядит хорошо:

1. Серверная сторона: человек заполняет & отправляет регистрационную форму, затем получает сообщение об ошибке при перезагрузке. Пробует другой простой пароль и получает другое сообщение об ошибке при перезагрузке. Даже если вы предоставите им список запрещенных паролей, такой опыт довольно расстраивает.

2. Клиентская сторона (JS, загруженная со страницы) : пользователь заполняет поле пароля & получает уведомление о размытии в режиме реального времени. Он может попробовать другой простой пароль или просто добавить простого персонажа в конце, чтобы «закрыть его». В конце концов проблема с паролем не решена.

Вместо этого вы должны показать своим пользователям, что их пароли слабы с помощью счетчика паролей, который является проверенным методом повышения надежности пароля. Недавняя статья Включение выбора пароля пользователя через одноранговое давление ( Декабрь 2011 г.) исследовали, будут ли индикаторы давления сверстников (например, «ваш пароль слабее X% пользователей») более эффективны, чем счетчики паролей. Результаты были неубедительными между двумя методами влияния на силу пароля, но оба метода показали статистически значимое улучшение по сравнению с отсутствием индикаторов (см. Раздел 4, начиная со стр. 39 отчета - (стр. 52 фактического PDF)).

В терминах специальных счетчиков паролей Dropbox zxcvbn (GitHub). Он основан на сложных вычислениях энтропии, которые подробно описаны в их техническом блоге и знаменитом комиксе xckd о правильном штанге батареи для лошади .

Если вы пытаетесь предотвратить базовое «ручное» злоупотребление, то есть Джон сидит за своим столом и пытается войти в аккаунт Алисы, угадывая свой пароль, - тогда непременно пойти дальше и запретить верхнюю 25. Если вы «пытаясь защитить от более серьезных попыток взлома, не поддайтесь никаким иллюзиям, что это что-то достигнет. Атака по словарю не различает никаких двух паролей с одним словом, а для большинства - стандартную замену букв i на обертывание цифрой 1. Если вы действительно хотите, чтобы ваши пользователи получили одолжение, установите разумную минимальную длину (не менее 14 символов) и не , чтобы обеспечить максимальный уровень. Нет причин для обеспечения максимальной длины пароля (кроме того, что можно разумно передать по сети), поскольку пароли должны быть в одностороннем порядке зашифрованы до того, как они будут сохранены.

По умолчанию я бы не запретил общие пароли, но я бы поставил индикатор силы, чтобы дать пользователям четкую обратную связь о том, как «безопасный» является их паролем. Имейте в виду, что пароль является личным выбором, и если вы не разъясняете им, пользователи имеют право выбрать любой пароль.

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