Должен ли я установить максимальную длину для паролей?
Я понимаю, что установление минимальной длины паролей имеет большой смысл (чтобы спасти пользователей от самих себя), но мой банк требует, чтобы пароли были длиной от 6 до 8 символов, и я начал задаваться вопросом...
- Разве это не облегчит атаки грубой силы? (Плохой)
- Означает ли это, что мой пароль хранится в незашифрованном виде? (Плохой)
Если кто-то с (надеюсь) несколькими хорошими специалистами по информационной безопасности, работающими на них, устанавливает максимальную длину пароля, я должен подумать о том, чтобы сделать подобное? Каковы плюсы / минусы этого?
24 ответа
Пароли хешируются до 32, 40, 128 любой длины. Единственная причина минимальной длины состоит в том, чтобы предотвратить угадывание паролей. Там нет цели для максимальной длины.
Обязательный XKCD, объясняющий, почему вы наносите вред своему пользователю, если вы навязываете максимальную длину:
Максимальная длина, указанная в поле пароля, должна читаться как ПРЕДУПРЕЖДЕНИЕ О БЕЗОПАСНОСТИ: Любой здравомыслящий, заботящийся о безопасности пользователь должен предполагать худшее и ожидать, что этот сайт хранит ваш пароль буквально (т.е. не хешируется, как объяснил epochwolf).
В этом случае: (а) по возможности избегайте использования этого сайта, как чумы [они, очевидно, знают о безопасности гайки] (б) если вы должны использовать сайт, убедитесь, что ваш пароль уникален - в отличие от любого пароля, который вы используете в другом месте,
Если вы разрабатываете сайт, который принимает пароли, НЕ устанавливайте глупый лимит паролей, если только вы не хотите получить смолу с помощью той же кисти.
[Внутренне, конечно, ваш код может обрабатывать только первые 256/1028/2k/4k(независимо от) байтов как "значимые", чтобы избежать взлома гигантских паролей.]
Учетная длина неограниченной длины пароля имеет один существенный недостаток, если вы принимаете пароль из ненадежных источников.
Отправитель может попытаться дать вам такой длинный пароль, что это приведет к отказу в обслуживании для других людей. Например, если пароль составляет 1 ГБ данных, и вы тратите все свое время на его принятие, пока не закончится память. Теперь предположим, что этот человек посылает вам этот пароль столько раз, сколько вы готовы принять. Если вы не будете осторожны с другими параметрами, это может привести к DoS-атаке.
Установление верхней границы для чего-то вроде 256 символов кажется слишком щедрым по сегодняшним стандартам.
Ограничение максимальной длины пароля теперь не рекомендуется в 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
Длина пароля Более длинные пароли обеспечивают большую комбинацию символов и, следовательно, затрудняют угадывание злоумышленником.
...
Максимальная длина пароля не должна быть установлена слишком низкой, так как это помешает пользователям создавать пароли. Типичная максимальная длина составляет 128 символов. Парольные фразы длиной менее 20 символов обычно считаются слабыми, если они состоят только из строчных латинских символов.
Хранилище дешево, зачем ограничивать длину пароля. Даже если вы шифруете пароль, а не просто хешируете его, 64-символьная строка не займет намного больше, чем 6-символьная строка для шифрования.
Скорее всего, банковская система перекрывает более старую систему, чтобы они могли выделить только определенное количество места для пароля.
В .net core 6 я использую метод HashPasswordV3, который использует HMACSHA512 с 1000 итераций. Я проверил некоторую длину пароля, и он сгенерировал 86-символьный хэш.
Поэтому я установил поле PasswordHash на сервере sql для varchar(100).
Старайтесь не вводить никаких ограничений, если это необходимо. Имейте в виду: это может и понадобится во многих различных случаях. Работа с устаревшими системами является одной из этих причин. Убедитесь, что вы хорошо тестировали случай очень длинных паролей (может ли ваша система работать с 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/
Если вы принимаете пароль произвольного размера, тогда предполагается, что он усекается до длины занавеса по соображениям производительности до того, как его хешируют. Проблема с усечением заключается в том, что, поскольку производительность вашего сервера со временем увеличивается, вы не можете легко увеличить длину перед усечением, поскольку его хэш будет явно другим. Конечно, у вас может быть переходный период, когда обе длины хэшируются и проверяются, но это требует больше ресурсов.
Последние обновления от OWASP теперь рекомендуют максимальную длину:https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html
Максимальная длина пароля не должна быть слишком маленькой, так как это не позволит пользователям создавать парольные фразы. Обычная максимальная длина составляет 64 символа из-за ограничений в некоторых алгоритмах хеширования, как описано в Памятке по хранению паролей. Важно установить максимальную длину пароля, чтобы предотвратить атаки типа «отказ в обслуживании» с длинным паролем .
Мой банк тоже это делает. Раньше было разрешено использовать любой пароль, а у меня был 20-значный. Однажды я изменил его, и вот, это дало мне максимум 8, и я вырезал не алфавитно-цифровые символы, которые были в моем старом пароле. Не имеет никакого смысла для меня.
Все бэкэнд-системы в банке работали раньше, когда я использовал свой пароль из 20 символов с не буквенно-цифровыми значениями, поэтому устаревшая поддержка не могла быть причиной. И даже если бы это было так, они все равно должны позволять вам иметь произвольные пароли, а затем создавать хэш, который соответствует требованиям унаследованных систем. Более того, они должны исправить устаревшие системы.
Решение со смарт-картой не подошло бы мне. У меня уже слишком много карт, как есть... Мне не нужен еще один трюк.
Одна из причин, по которой пароли могут не хэшироваться, - это используемый алгоритм аутентификации. Например, некоторые алгоритмы дайджеста требуют, чтобы на сервере была открыта незашифрованная версия пароля, поскольку механизм аутентификации предполагает, что и клиент, и сервер выполняют одну и ту же математику с введенным паролем (что, как правило, не выдает тот же результат каждый раз, что и пароль). объединяется со случайно сгенерированным "nonce", который разделяется между двумя машинами).
Часто это может быть усилено, так как дайджест может быть частично вычислен в некоторых случаях, но не всегда. Лучшим способом является сохранение пароля с обратимым шифрованием - это означает, что источники приложения должны быть защищены, так как они будут содержать ключ шифрования.
Дайджест-аутентификация предназначена для аутентификации по незашифрованным каналам. При использовании SSL или какого-либо другого полноканального шифрования нет необходимости использовать механизмы дайджест-аутентификации, то есть вместо этого пароли могут храниться хэшированными (так как пароли могут быть отправлены в незашифрованном виде по проводам безопасно (для заданного значения safe).
Должна ли быть максимальная длина? Это очень любопытная тема в ИТ, так как более длинные пароли, как правило, труднее запомнить, и, следовательно, они с большей вероятностью будут записаны (БОЛЬШОЕ нет-нет по очевидным причинам). Более длинные пароли также имеют тенденцию забываться больше, что, хотя и не обязательно представляет угрозу безопасности, может привести к административным трудностям, снижению производительности и т. Д. Администраторы, которые считают, что эти проблемы являются неотложными, могут навязать паролям максимальную длину.
Я лично верю в этом конкретном вопросе, каждому пользователю свое. Если вы думаете, что можете вспомнить 40-символьный пароль, то тем более силен для вас!
Сказав, что, хотя пароли быстро становятся устаревшим режимом безопасности, Smart Cards и проверка подлинности сертификатов оказываются очень трудными или невозможными, поскольку вы заявили, что это проблема, и на стороне сервера должен храниться только открытый ключ с частным ключ на вашей карте / компьютере всегда.
Устаревшие системы (уже упоминавшиеся) или взаимодействие с системами сторонних производителей могут потребовать ограничения в 8 символов. Это также может быть ошибочной попыткой спасти пользователей от самих себя. Такое ограничение приведет к слишком большому количеству паролей pssw0rd1, pssw0rd2 и т. Д. В системе.
Я обнаружил, что использование одних и тех же символов для первых 72 байтов пароля дает успешную проверку с использованием
password_hash()а также
password_verify()в PHP независимо от того, какая случайная строка идет после первых 72 байтов.
Из документов PHP: https://www.php.net/manual/en/function.password-hash.php
Внимание ! Использование PASSWORD_BCRYPT в качестве алгоритма приведет к усечению параметра пароля до максимальной длины 72 байта.
Microsoft публикует рекомендации по безопасности для разработчиков, основанные на их внутренних данных (вы знаете, от запуска крупнейшего предприятия по разработке программного обеспечения в истории вычислений), и вы можете найти эти PDF-файлы в Интернете. Microsoft заявила, что не только взлом паролей является наименьшей из их проблем с безопасностью, но и то, что:
«Преступники пытаются преследовать наших клиентов различными способами, и мы обнаружили, что подавляющее большинство атак осуществляется с помощью фишинга, компьютеров, зараженных вредоносным ПО, и повторного использования паролей на сторонних сайтах — ни одному из них не помогают очень длинные пароли». -Майкрософт
Собственная практика Microsoft заключается в том, что пароли не могут быть длиннее 16 и не короче 8 символов.
Более длинные пароли или парольные фразы сложнее взломать, просто основываясь на длине, и их легче запомнить, чем требовать сложного пароля.
Наверное, лучше всего пойти на довольно большую (10+) минимальную длину, ограничив бесполезную длину.
Просто 8 символов длинных паролей звучат просто неправильно. Если должен быть предел, то, по крайней мере, 20 символов лучше.
Я думаю, что единственное ограничение, которое должно быть применено, это как ограничение в 2000 букв или что-то еще слишком высокое, но только для ограничения размера базы данных, если это проблема