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

максимальная длина, указанная в поле пароля, должна быть прочитана как ПРЕДУПРЕЖДЕНИЕ БЕЗОПАСНОСТИ: Любой разумный, сознательный пользователь безопасности должен предположить худшее и ожидать, что этот сайт хранит ваш пароль буквально (т. е. не хэшируется, как объяснил epochwolf).

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

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

[внутренне, конечно, ваш код может рассматривать только первые 256/1028/2k / 4k(что угодно) байты как "значительные", чтобы избежать хруста на Мамонтовых паролях.]

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

отправитель может попытаться дать вам такой длинный пароль, что это приводит к отказу в обслуживании для других людей. Например, если пароль составляет 1 ГБ данных, и вы тратите все свое время, примите его, пока не закончится память. Теперь предположим, что этот человек посылает вам этот пароль столько раз, сколько вы готовы принять. Если вы не будете осторожны другие параметры, связанные с этим, могут привести к DoS-атаке.

установка верхней границы на что-то вроде 256 символов кажется чрезмерно щедрым по сегодняшним стандартам.

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

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

максимальный предел длины пароля теперь не рекомендуется OWASP аутентификации шпаргалка

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

цитируя весь абзац:

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

минимальная длина паролей должна быть применена приложением. Пароли короче 10 символов, считаются слабыми ([1]). В то время как применение минимальной длины может вызвать проблемы с запоминанием паролей среди некоторых пользователей, приложения должны поощрять их устанавливать парольные фразы (предложения или комбинации слов), которые могут быть намного длиннее, чем обычные пароли, и все же намного легче запомнить.

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

убедитесь, что каждый символ, который вводит пользователь, фактически включен в пароль. Мы видели системы, которые усекают пароль на длину короче, чем то, что пользователь предоставил (например, усекли на 15 символов, когда они ввели 20). Это обычно обрабатывается путем установки длины всех полей ввода пароля, чтобы быть точно та же длина, что и пароль максимальной длины. Это особенно важно, если максимальная длина пароля короткая, например 20-30 символов.

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

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

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

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

трудно найти какое-либо оправдание для ограничения длины пароля, кроме плохого дизайна.

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

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

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

Мой банк тоже. Раньше он разрешал любой пароль, и у меня был 20-символьный. Однажды я изменил его, и вот он дал мне максимум 8, и вырезал не буквенно-цифровые символы, которые были в моем старом пароле. Для меня это не имело никакого смысла.

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

решение смарт-карты не пойдет хорошо со мной. У меня и так уже слишком много карт... Мне не нужен еще один трюк.

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

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

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

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

...

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

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

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

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

более длинные пароли или фразы-пароли сложнее взломать просто на основе длины и легче запомнить, чем требовать сложный пароль.

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

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

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

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

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

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

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

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