Требуется пароль специальный символ против пароля Дополнительный специальный символ - PullRequest
Новая
       37

Требуется пароль специальный символ против пароля Дополнительный специальный символ

3 голосов
/ 06 ноября 2019

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

Допустим, кто-то хочет взломать пароль, разве им было бы легче, если бы они уже знали, что этот пароль содержит как минимум 1 специальный символ, 1 заглавную и строчную буквы и 1 цифру, потому что это было необходимо? ,Вместо возможности для пароля содержать эти символы, если он был разрешен вместо обязательных?

Ответы [ 2 ]

3 голосов
/ 07 ноября 2019

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

В процессе разработки вы можете использовать OWASP ASVS, расположенный здесь: https://github.com/OWASP/ASVS/blob/master/4.0/en/0x11-V2-Authentication.md

Есть контрольный списокнапример:

  1. Убедитесь, что длина паролей, заданных пользователем, не менее 12 символов.
  2. Убедитесь, что имеется измеритель надежности пароля, чтобы помочь пользователям установить более надежный пароль.

Если вы следуете некоторым стандартам, таким как OWASP, защита вашей аутентификации будет хорошей.

0 голосов
/ 08 ноября 2019

Разве не было бы безопаснее разрешить вместо того, чтобы требовать эти символы?

Да и нет.

Нет: Как ФрэнсисАль Викториано сказал, что полезно противостоять атакам по словарю.

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

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

Итак, должны ли мы заставить пользователя иметь несколько кодировок в своем пароле?

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

Некоторые говорят, что мы не должны (например, NIST ), потому что:

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

  • Говоря об обходе, типичная политика паролей - минимум 8 символов, как минимум одна заглавная, одна строчная, одна цифра и один специальный символ. Вот, пожалуйста: P@ssw0rd. Давайте проверим, считает ли я Pwned хорошим паролем , оповещение о спойлере: нет.

  • Запрещает пользователям выбирать парольную фразу.

Мое предположение заключается в том, чтобы следовать рекомендациям NIST:

  1. Минимальная длина 12 символов
  2. Измеритель надежности пароля, основанный на актуальном спискеутечек паролей (например, HIBP ) и автономной оценки надежности (например, zxcvbn ), чтобы помочь пользователям избежать слабых паролей
  3. (необязательно) Проверка надежности пароля на стороне сервера (на основе двух компонентов шага 2), если вы хотите убедиться, что ваш пользователь выбирает надежный пароль, и вы не хотите, чтобы он или не позволял ему игнорировать обратную связь измерителя надежности пароля.
...