Должен ли я устанавливать максимальную длину паролей?
https://stackoverflow.com/questions/98768
-
01-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Я понимаю, что установление минимальной длины паролей имеет большой смысл (чтобы уберечь пользователей от самих себя), но мой банк есть требование, чтобы пароли имели длину от 6 до 8 символов, и я начал задаваться вопросом...
- Не облегчит ли это атаку методом грубой силы?(Плохой)
- Означает ли это, что мой пароль хранится в незашифрованном виде?(Плохой)
Если кто-то, у кого (надеюсь) работают хорошие специалисты по ИТ-безопасности, устанавливает максимальную длину пароля, стоит ли мне подумать о том, чтобы сделать то же самое?Каковы плюсы/минусы этого?
Решение
Пароли хешируются до 32, 40, 128 любой длины.Единственная причина минимальной длины — это предотвращение легкого подбора паролей.Нет смысла устанавливать максимальную длину.
Обязательный XKCD объясняя, почему вы оказываете пользователю медвежью услугу, если устанавливаете максимальную длину:
Другие советы
Максимальную длину, указанную в поле пароля, следует читать как ПРЕДУПРЕЖДЕНИЕ БЕЗОПАСНОСТИ:Любой разумный пользователь, заботящийся о безопасности, должен предполагать худшее и ожидать, что этот сайт хранит ваш пароль буквально (т.не хешируется, как объяснил epochwolf).
В том то и дело:(а) Избегайте использования этого сайта, например, чумы, если это возможно, [они, очевидно, знают орехи о безопасности] (b) Если вам необходимо использовать сайт, убедитесь, что ваш пароль уникален - в отличие от любого пароля, который вы используете в других местах.
Если вы разрабатываете сайт, который принимает пароли, НЕ устанавливайте глупые ограничения на количество паролей, если только вы не хотите, чтобы вас заклеймили той же кистью.
[Внутренне, конечно, ваш код может обрабатывать только первые 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 символов.
Одна из причин, по которой я могу предположить необходимость соблюдения максимальной длины пароля, заключается в том, что интерфейс должен взаимодействовать со многими устаревшими серверными системами, один из которых сам обеспечивает максимальную длину пароля.
Другой мыслительный процесс может заключаться в том, что если пользователь вынужден использовать короткий пароль, он с большей вероятностью придумает случайную тарабарщину, чем легко угадываемую (его друзьями/семьей) крылатую фразу или прозвище.Этот подход, конечно, эффективен только в том случае, если интерфейс принудительно смешивает цифры и буквы и отклоняет пароли, в которых есть слова из словаря, включая слова, написанные на l33t-speak.
Одной из потенциально веских причин для введения некоторой максимальной длины пароля является то, что процесс его хеширования (из-за использования функции медленного хеширования, такой как bcrypt) занимает слишком много времени;что-то, чем можно злоупотребить для проведения DOS-атаки на сервер.
Опять же, серверы должны быть настроены на автоматическое удаление обработчиков запросов, которые занимают слишком много времени.Поэтому я сомневаюсь, что это будет большой проблемой.
Я думаю, что вы совершенно правы по обоим пунктам.Если они хранят пароли в хешированном виде, как и должно быть, длина пароля вообще не влияет на схему их БД.Наличие неограниченной длины пароля добавляет еще одну переменную, которую злоумышленнику приходится учитывать.
Трудно найти какое-либо оправдание ограничению длины пароля, кроме плохого дизайна.
Единственное преимущество, которое я вижу в максимальной длине пароля, — это устранение риска атаки переполнения буфера, вызванной слишком длинным паролем, но есть гораздо лучшие способы справиться с этой ситуацией.
Хранение дешевое, зачем ограничивать длину пароля.Даже если вы шифруете пароль, а не просто хешируете его, для шифрования строки из 64 символов не потребуется намного больше, чем строка из 6 символов.
Скорее всего, банковская система перекрывает более старую систему, поэтому они смогли выделить только определенное количество места для пароля.
Мой банк тоже так делает.Раньше можно было использовать любой пароль, а у меня был пароль из 20 символов.Однажды я изменил его, и, о чудо, он дал мне максимум 8 и вырезал небуквенно-цифровые символы, которые были в моем старом пароле.Для меня это не имело никакого смысла.
Все серверные системы в банке работали раньше, когда я использовал свой 20-символьный пароль, не состоящий из букв и цифр, поэтому устаревшая поддержка не могла быть причиной.И даже если бы это было так, они все равно должны позволять вам иметь произвольные пароли, а затем создавать хэш, соответствующий требованиям устаревших систем.А еще лучше, им следует исправить устаревшие системы.
Решение со смарт-картой мне не подошло.У меня и так слишком много карточек...Мне не нужен еще один трюк.
Если вы принимаете пароль произвольного размера, то предполагается, что он усекается до длины занавеса из соображений производительности перед хешированием.Проблема с усечением заключается в том, что по мере того, как производительность вашего сервера со временем увеличивается, вы не можете легко увеличить длину до усечения, поскольку его хэш явно будет другим.Конечно, у вас может быть переходный период, когда обе длины хэшируются и проверяются, но это требует больше ресурсов.
Не обращайте внимания на людей, которые говорят не проверять длинные пароли.Owasp буквально говорит, что 128 символов должно быть достаточно.Просто чтобы дать достаточно места для дыхания, вы можете дать немного больше, скажем, 300, 250, 500, если хотите.
https://www.owasp.org/index.php/Authentication_Cheat_Sheet#Password_Length
Длина пароля длинные пароли обеспечивают большую комбинацию символов и, следовательно, затрудняют угадать злоумышленника.
...
Максимальная длина пароля не должна быть установлена слишком низкой, так как это не позволит пользователям создавать пасфразы. Типичная максимальная длина составляет 128 символов.Пассные фразы короче 20 символов обычно считаются слабыми, если они состоят только из латинских символов нижнего регистра.
Должна ли быть максимальная длина?Это любопытная тема в ИТ, поскольку более длинные пароли, как правило, труднее запомнить, и поэтому их с большей вероятностью запишут (Большое нет-нет по понятным причинам).Более длинные пароли также чаще забываются, что, хотя и не обязательно представляет угрозу безопасности, может привести к административным проблемам, снижению производительности и т. д.Администраторы, которые считают, что эти проблемы актуальны, скорее всего, установят максимальную длину паролей.
Я лично считаю, что в этом конкретном вопросе каждому пользователю свое.Если вы думаете, что можете запомнить пароль из 40 символов, то тем больше вам сил!
Однако, несмотря на это, пароли быстро становятся устаревшим способом безопасности, смарт-карты и аутентификация сертификатов оказываются очень трудными или невозможными для перебора, как вы заявили, это проблема, и на сервере необходимо хранить только открытый ключ вместе с частным ключ всегда на вашей карте/компьютере.
Более длинные пароли или парольные фразы труднее взломать просто из-за их длины, и их легче запомнить, чем требовать сложный пароль.
Вероятно, лучше всего выбрать довольно большую (10+) минимальную длину, ограничивая ее бесполезно.
Устаревшие системы (уже упомянутые) или взаимодействующие с системами сторонних поставщиков могут потребовать ограничения в 8 символов.Это также может быть ошибочной попыткой спасти пользователей от самих себя.Такое ограничение приведет к появлению слишком большого количества pssw0rd1, pssw0rd2 и т. д.пароли в системе.
Одной из причин, по которой пароли не могут быть хешированы, является используемый алгоритм аутентификации.Например, некоторые алгоритмы дайджеста требовать версию пароля в виде открытого текста на сервере, поскольку механизм аутентификации предполагает, что и клиент, и сервер выполняют одни и те же математические вычисления с введенным паролем (который, как правило, не выдает один и тот же результат каждый раз, поскольку пароль объединяется со случайно сгенерированным паролем). «nonce», который используется двумя машинами).
Часто это можно усилить, поскольку в некоторых случаях, но не всегда, дайджест может быть частично вычислен.Лучше всего хранить пароль с обратимым шифрованием. Это означает, что источники приложения должны быть защищены, поскольку они будут содержать ключ шифрования.
Digst auth предназначен для обеспечения аутентификации по незашифрованным каналам.При использовании SSL или другого полноканального шифрования нет необходимости использовать механизмы дайджест-аутентификации, а это означает, что вместо этого пароли можно хранить в хешированном виде (поскольку пароли могут быть безопасно отправлены в виде открытого текста по сети (для заданного значения Safe).
Постарайтесь не вводить никаких ограничений без необходимости.Имейте в виду:это может и будет необходимо во многих разных случаях.Одной из таких причин является работа с устаревшими системами.Убедитесь, что вы хорошо протестировали очень длинные пароли (сможет ли ваша система справиться с паролями длиной 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/
Пароли длиной всего 8 символов звучат просто неправильно.Если должен быть предел, то лучше использовать не менее 20 символов.
Я думаю, что единственное ограничение, которое следует применить, — это ограничение в 2000 букв или что-то еще безумно высокое, но только для ограничения размера базы данных, если это проблема.
