Стратегии сложности паролей - есть ли доказательства для них? - PullRequest
7 голосов
/ 19 января 2009

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

  • Пароли должны содержать не менее N символов;
  • Пароли должны включать строчные, прописные и цифры;
  • Нет повторного использования последних M паролей (или паролей, используемых в течение P дней).

и т. Д.

Что-то всегда мешало мне устанавливать ограничения на пароли any - ограничивая доступные пароли, вы уменьшаете размер пространства всех допустимых паролей. Разве это не делает пароли проще угадать?

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

Есть ли количественные доказательства того, что правила ограничения паролей делают системы более безопасными?

Если есть, какие «наиболее безопасные» стратегии ограничения паролей использовать?


Редактировать Олафур Вааге любезно указал на статью Coding Horror о атаках по словарям , в которой содержится много полезного анализа, но мне кажется, что атаки по словарям могут быть значительно сокращены (как предлагает Джефф), просто добавив задержку после неудачной попытки аутентификации.

Имея это в виду, что свидетельствует о том, что сложные пароли являются более безопасными?

Ответы [ 10 ]

5 голосов
/ 19 января 2009

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

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

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

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

3 голосов
/ 19 января 2009

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

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

НО мои большие домашние животные - ограничения на пароли, с которыми я сталкивался на крупных сайтах, например

  • Никаких специальных символов
  • Максимальная длина

Зачем кому-то это делать? W.H.Y.????

2 голосов
/ 19 января 2009

Моя старая предельная теорема:

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

2 голосов
/ 19 января 2009
  1. Никогда не позволяет пользователю делать то, что он действительно хочет, если только нет технических ограничений.
  2. Вы, возможно, чертовски недовольны тем, что делаете глупости, например, пользуетесь словарным словом или трехзначным паролем, или используете только цифры, но см. Выше # 1.
  3. Нет веских технических причин требовать только буквенно-цифровые цифры, или хотя бы одну заглавную букву или хотя бы одну цифру; см. № 1 выше.

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

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

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

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

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

На днях мне придется сделать запись в блоге на эту тему. (

2 голосов
/ 19 января 2009

Хорошее чтение этой статьи - статья Джеффа о атаках по словарям.

1 голос
/ 19 января 2009

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

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

1 голос
/ 19 января 2009

Можно также отметить недавнее фиаско в твиттере, где один из паролей их администратора оказался «счастьем», что привело к атаке по словарю.

0 голосов
/ 08 февраля 2015

Лично для этой специфической проблемы я склонен ставить паролям «оценку» на основе характеристик введенного текста и отказываться от паролей, которые не соответствуют этой оценке.

Например:

Contains Lower Case Letter +1

Contains different Lower Case Letter +1

Contains Upper Case Letter +1

Contains different Upper Case Letter +1

Contains Non-Alphanumeric character: +1

Contains different Non-Alphanumeric character: +1

Contains Number: +1

Contains Non Consecutive or repeated Second Number: +1 

Length less than 8: -10 

Length Greater than 12: +1

Contains Dictionary word: -4

Тогда разрешается только пароли со счетом больше 4 (и предоставление обратной связи с пользователями, когда они создают свой пароль через javascript)

0 голосов
/ 09 мая 2014

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

Но у меня есть КОНКРЕТНАЯ говядина с чувствительностью к регистру.

Для начала, пользователи ненавидят это. Человеческий мозг думает "А = а". Конечно, мозги разработчиков обычно не типичны. ;-) Но разработчиков также беспокоит чувствительность к регистру.

Во-вторых, клавиша CapsLock слишком легко попасть по ошибке. Он находится между клавишами Tab и Shift, но ДОЛЖЕН быть над клавишей Esc. Его местонахождение было установлено давно во времена пишущих машинок, у которых не было альтернативного шрифта. В те дни было полезно иметь его там.

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

МОЙ АРГУМЕНТ: Да, чувствительность к регистру более безопасна для данной длины пароля. Но если кто-то не заставляет меня поступить иначе, я выбираю более длинную минимальную длину пароля. Даже если предположить, что разрешены только буквы и цифры, каждый добавленный символ умножает количество возможных паролей на 36.

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

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

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

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

PIN-код для моей банковской карты состоит из четырех цифр. Так как это только цифры, он не чувствителен к регистру. И, черт возьми, это мои ДЕНЬГИ! Если вы не учитываете ничего другого, это звучит довольно небезопасно, если бы не тот факт, что хакер должен украсть мою карту, чтобы получить мои деньги. (И сфотографироваться.)

Еще одна претензия: разработчики, которые заходят на StackOverflow и извергают жесткие правила, которые они где-то читали в статье. «Никогда ничего не кодируй жестко». (Как будто это возможно.) «Все запросы должны быть параметризованы» (не если пользователь не вносит свой вклад в запрос.) И т. Д.

Пожалуйста, извините напыщенную речь. ;-) Обещаю, я уважаю разногласия.

0 голосов
/ 19 января 2009

Хотя это и не дает прямого ответа на ваш вопрос, лично я нахожу самое обидное правило, с которым я столкнулся, когда вы не можете повторно использовать любой ранее использованный пароль. После нескольких лет работы в одном и том же месте и необходимости смены пароля каждые 2/3 месяца возможность использовать пароль, который я выбрал более года назад, не будет особенно небезопасной или небезопасной. Если бы я использовал «безопасные» пароли в прошлом (буквенно-цифровые с изменениями в регистре), то, конечно, их повторное использование через период, скажем, год или 2 (в зависимости от того, как часто вы должны менять свой пароль), мне кажется приемлемым , Это также означает, что я с меньшей вероятностью буду использовать «более простые» пароли, что может произойти, если я не могу придумать ничего, что легко запомнить и трудно угадать!

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