2009-10-21 2 views
3

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

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

Я как-то на правильном пути с этим?

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

Update Для тех, кто прибывает поздно вопрос

Таким образом, общий консенсус, кажется, подтверждающее то, что я сначала подумал, что риск бессловесных сил возрастают. Тем не менее, работа крекциониста RT не будет настолько сложной из-за того, что у них нет никаких указаний относительно размера. На самом деле это можно упростить, так как в любом случае они начинаются с нижних таблиц символов. Верный? (Не говоря уже о нетехнических проблемах, которые в настоящее время придуманы, глядя на чье-то плечо и т. Д., Которые не так важны для более длительного пароля.)

Таким образом, вывод: даже если вы hash/соль пароль, короткие пароли по-прежнему представляют собой риск

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

+1

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

ответ

1

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

+3

14 или более? Я бы никогда не захотел войти в ваши приложения. – JonH

+1

@JonH - Это не минимум, но верхний предел, заданный в вопросе. –

+0

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

2

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

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

+1

Даже если пользователи использовали специальные символы (которых у них нет), 7-символьный пароль - это всего лишь 46-битное пространство. Слишком мало. – erickson

+1

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

+3

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

1

# 3 является ключом: 2-3 паролей символов слишком уязвимы для атак со словарями (слишком мало комбинаций и, таким образом, могут включать вселенную в комбинации атак).

Верхний предел не имеет значения, но что-либо более 20 символов означает, что пользователь скорее всего будет копировать/вставлять, что является плохой практикой, которую не следует поощрять.

+3

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

+2

Я сказал «скорее всего», а не «всегда» :) - вы являетесь исключением, но подавляющее большинство пользователей не смогут обрабатывать ввод пароля> 20char, даже если это фраза. Это не только проблема запоминания, но и набора текста. – DVK

+1

«Dice words» и другие методы могут легко создавать безопасные, запоминающиеся пароли длиной более 20 символов. – erickson

1

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

Что касается максимальной длины, у вас не должно быть ни одного.

5

Нет. Это просто глупо.

Если ваши пароли properly hashed and salted, радужные столы не являются проблемой, кстати.

+0

+1 для ссылки – DVK

1

Это позволяет вашим пользователям очень восприимчивым к незнакомцам, поглядывающим на их плечи, не так ли?

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

1

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

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

+4

Просмотр ввода пароля не является социальной инженерией. Социальная инженерия позиционирует себя как заслуживающего доверия человека/авторитета, чтобы заставить пользователя добровольно выдавать свой пароль. – ty812

+1

Итак, есть ли технический термин для «поиска пароля через физическое/личное взаимодействие»? –

+1

Возможно, «социальная инженерия» - не правильный термин, но, безусловно, правильный ответ. – Chris

6

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

+1

Не обязательно верно. Представьте, что стандартные пользовательские настройки ограничены стандартными ключами, например: 52 для букв, 20 для цифр и сдвинутых символов и 22 для других стандартных символов, поэтому пул, скажем, 94. Хотя это может дать пользователю (и разрешено символов), он создает * whopping * 8836 вариантов на 2 символа. (Тем не менее, я согласен, что этот пул тривиально мал). – 2009-10-21 19:16:03

+1

Но дроссель в действии тоже, это все еще проблема? – Chris

+1

Зависит. Представьте сценарий, что одна попытка может быть сделана каждые 10 секунд, и злоумышленник начинает грубую силу с двумя символами (например, они провели исследование): 8836 вариантов можно было взломать не более 88360 секунд (~ 1 день). Однако «средний» был бы вдвое меньше, и более разумный выбор генерации грубой силы, основанный на частотах символов, мог бы еще больше уменьшить это. – 2009-10-21 19:37:53

2

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

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

Лично я раздражаюсь, когда сайту требуется какой-то ужасно сложный пароль. Я думаю, что 6 символов, включая один символ/номер, являются справедливым требованием, например, для такого сайта, как stackoverflow. На моем банковском счете? Давайте просто скажем, что пароль несколько сложнее.

Но есть дополнительные проблемы фундаментальной безопасности:

  • перебор и атаки по словарю только практически работать, если тесты могут быть применены [очень] быстро. Вот почему современные UNIX-системы используют теневой файл паролей - это сводит к минимуму вероятность сбора паролей для атак с использованием грубой силы. Хотя «локауты» могут раздражать, они также могут практически предотвращать простые грубые силы.
  • Социальная инженерия: «Могу ли я сыграть вашего персонажа?» Как называется твоя девушка? Вы пишете пароль или показываете его во время ввода? (Кто-нибудь смотрит?) Используется ли пароль, который вы используете для разных сайтов/целей?
  • Есть ли другие функции «кругосветного плавания»? Может ли пароль быть сброшен или текущий пароль отправлен по электронной почте? Какие существуют ограничения при сбросе?
  • Является ли безопасность скомпрометирована с помощью других средств (HTTP против HTTPS или telnet против SSH, доступного хранилища с открытым текстом и т. Д.).
  • И самым большим peeve: Стандартные вопросы безопасности. Google для «Сара Пэйлин Email взломан». Пожалуйста, пожалуйста, не пропустите этот маршрут без тщательного рассмотрения.
+0

Больше семантики вытащили из того, что, как представляется, является учебным пособием ISC2 , Один только пароль небезопасен, независимо от того, какое хеширование, засоление или шифрование на уровне линии находятся в игре, потому что это единственный метод безопасности: что-то вы знаете. Безопасность - это слои и обсчет. –

1

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

Смежные вопросы