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

Ответ 1

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

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

Ответ 2

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

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

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

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

Ответ 3

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

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

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

Ответ 4

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

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

Ответ 5

Максимальное ограничение длины пароля теперь обескураживается чит-листом проверки подлинности OWASP

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

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

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

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

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

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

Ответ 6

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

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

Ответ 7

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

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

Ответ 8

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

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

Ответ 9

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

Ответ 10

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

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

Ответ 11

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

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

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

Ответ 12

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

Ответ 13

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

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

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

...

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

Ответ 14

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

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

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

Ответ 15

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

Ответ 16

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

Ответ 17

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

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

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

Ответ 18

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

Ответ 19

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

Ответ 20

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