Нужно ли вводить максимальную длину для паролей?

Question

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

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

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

Answer 1

Не обращайте внимания на людей, говорящих не проверять длинные пароли. Овасп буквально говорит, что 128 символов должно быть достаточно. Просто чтобы дать достаточное пространство для дыхания, вы можете дать чуть больше, скажем, 300, 250, 500, если захотите.

https://www.owasp.org/index.php/Authentication_Cheat_Sheet#Password_Length

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

...

Максимальная длина пароля не должна быть установлена ​​слишком низкой, так как это предотвратит пользователи от создания парольных фраз. Типичная максимальная длина составляет 128 символы . Парольные фразы длиной менее 20 символов обычно считается слабым, если они состоят только из строчных букв латинского алфавита.

Answer 2

Хранилище дешево, зачем ограничивать длину пароля. Даже если вы шифруете пароль, а не просто хешируете его, 64-символьная строка не займет намного больше, чем 6-символьная строка для шифрования.

Скорее всего, банковская система перекрывает более старую систему, поэтому они смогли выделить только определенное пространство для пароля.

Answer 3

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

Answer 4

Устаревшие системы (уже упоминавшиеся) или взаимодействие с системами сторонних производителей могут потребовать ограничения в 8 символов. Это также может быть ошибочной попыткой спасти пользователей от самих себя. Такое ограничение приведет к слишком большому количеству паролей pssw0rd1, pssw0rd2 и т. Д. В системе.

Answer 5

Старайтесь не налагать никаких ограничений, если в этом нет необходимости. Имейте в виду: это может и понадобится во многих различных случаях. Работа с устаревшими системами является одной из этих причин. Убедитесь, что вы хорошо тестировали случай очень длинных паролей (может ли ваша система работать с 10 МБ длинных паролей?). Вы можете столкнуться с проблемами отказа в обслуживании (DoS), потому что используемые вами функции определения ключа (KDF) (обычно PBKDF2, bcrypt, scrypt) отнимают много времени и ресурсов. Пример из реальной жизни: http://arstechnica.com/security/2013/09/long-passwords-are-good-but-too-much-length-can-be-bad-for-security/

Answer 6

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

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

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

Answer 7

Должна ли быть максимальная длина? Это очень любопытная тема в ИТ, так как более длинные пароли, как правило, труднее запомнить, и, следовательно, они с большей вероятностью будут записаны (БОЛЬШОЕ нет-нет по очевидным причинам). Более длинные пароли также имеют тенденцию забываться больше, что, хотя и не обязательно представляет угрозу безопасности, может привести к административным трудностям, снижению производительности и т. Д. Администраторы, которые считают, что эти проблемы являются неотложными, могут навязать паролям максимальную длину.

Я лично верю в этом конкретном вопросе, каждому пользователю свое. Если вы думаете, что можете вспомнить 40-символьный пароль, то тем более силен для вас!

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

Answer 8

Более длинные пароли или парольные фразы сложнее взломать, просто основываясь на длине, и их легче запомнить, чем требуя сложного пароля.

Вероятно, лучше всего пойти на довольно большую (10+) минимальную длину, ограничив бесполезную длину.

Answer 9

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

Answer 10

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