Должен ли я разрешить пароль из 2 символов? - PullRequest
3 голосов
/ 21 октября 2009

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

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

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

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

Обновление Для опоздавших на вопрос

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

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

Однако для длинных паролей я не уверен, что у меня есть окончательный ответ? Если я беспокоюсь о переполнении буфера, это все-таки обычное поле ввода.

Ответы [ 10 ]

6 голосов
/ 21 октября 2009

У злоумышленника останется всего 1296 вариантов угадать пароль конкретного пользователя.

5 голосов
/ 21 октября 2009

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

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

2 голосов
/ 21 октября 2009

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

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

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

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

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

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

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

1 голос
/ 06 ноября 2009

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

1 голос
/ 21 октября 2009

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

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

1 голос
/ 21 октября 2009

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

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

1 голос
/ 21 октября 2009

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

Относительно максимальной длины у вас не должно быть ни одной.

1 голос
/ 21 октября 2009

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

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

1 голос
/ 21 октября 2009

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

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