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

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

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

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

Пароли хэшируются до 32, 40, 128 любой длины. Единственная причина минимальной длины состоит в том, чтобы предотвратить легкое угадывание паролей. Там нет цели для максимальной длины.

Обязательный XKCD, объясняющий, почему вы оказываете вашим пользователям медвежью услугу, если вы навязываете максимальную длину:

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

В том, что это так:

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

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

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

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

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

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

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

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

Установка максимальной длины пароля менее 128 символов теперь не рекомендуется в OWASP Authentication Cheat Sheet

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

Ссылаясь на весь абзац:

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

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

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

Убедитесь, что каждый символ, который вводит пользователь, действительно включен в пароль. Мы видели системы, которые усекают пароль на длину, меньшую, чем та, которую предоставил пользователь (например, усекают до 15 символов, когда они вводят 20). Обычно это делается путем установки длины ВСЕХ полей ввода пароля равной длине максимальной длины пароля. Это особенно важно, если максимальная длина пароля короткая, например, 20-30 символов.

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

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

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

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

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

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

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

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

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

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

...

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

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

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

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

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

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

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

Старайтесь не вводить никаких ограничений, если это необходимо. Имейте в виду: это может и понадобится во многих различных случаях. Работа с устаревшими системами является одной из этих причин. Убедитесь, что вы хорошо тестировали случай очень длинных паролей (может ли ваша система работать с 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/

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

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

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

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

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

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

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

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

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

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

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