Какова предпочтительная длина имени пользователя и пароля? - PullRequest
11 голосов
/ 12 августа 2011

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

Заранее спасибо!

Ответы [ 4 ]

8 голосов
/ 12 августа 2011

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

ПЛОХАЯ ИДЕЯ - устанавливать ограничение на размер паролей.

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

Вторая причина заключается в том, что предлагает , чтобы вы хранили пароли в таблице базы данных. Это было бы БОЛЬШОЙ ОШИБКОЙ, потому что это потенциально оставляет пароли пользователей открытыми, если безопасность вашей системы поставлена ​​под угрозу. Вам следует хранить в базе данных соленый криптографический хеш пароля пользователя (который может иметь ограниченный размер) и проверять предложенный пароль, хэшируя его и сравнивая с сохраненным хешем.


Если вы говорите о минимальной длине (для паролей), вам, вероятно, следует сосредоточиться на энтропии, а не на длине пароля. (Пароль, состоящий из 20 «1», менее безопасен, чем случайно сгенерированная последовательность из 6 символов.)


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

(Должно быть солено ... мой плохой.)

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

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

Google Search для "энтропии паролей" или "мер энтропии паролей" даст вам некоторые сведения. А вот и один из ближайших:

(Примечание. Подход с использованием криптохеша - это НЕ ХРАНЕНИЕ пароля ... а не длина пароля. Плохой пароль будет небезопасным, независимо от того, как ваше программное обеспечение его обрабатывает.)

3 голосов
/ 12 августа 2011

Ограничения имени пользователя не являются большой проблемой, если вы не беспокоитесь о минимизации размера базы данных; но если это вызывает беспокойство, я сомневаюсь, что очень многие пользователи имеют имена пользователей длиннее 64 символов.

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

2 голосов
/ 30 марта 2015

Для меня я создаю имя пользователя varchar (25) и пароль varchar (100) почему? потому что я уже создал много учетных записей, и я обнаружил, что максимальная длина имени пользователя равна 21, а пароль - 26, но при шифровании пароля гораздо лучше использовать большой:)

желаю, чтобы это помогло вам

0 голосов
/ 12 августа 2011

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

В целом, если вы не продаете что-либо и небезопасный вход в систему влияет на ваши собственные данные, он должен быть как можно более надежным, означать СЛУЧАЙНЫЙ пароль (например: http://www.pctools.com/guides/password/) и, конечно, храниться в зашифрованной базе данных .

Редактировать: Шифрование далеко не достаточно, хеширование лучше, но все же не лучший подход. Хэширование, соление или растягивание хэша намного лучше. Хорошие посты, например Лучший способ сохранить пароль в базе данных или https://nakedsecurity.sophos.com/2013/11/20/serious-security-how-to-store-your-users-passwords-safely/.

...