какая должна быть минимальная длина пароля

Оптимальная длина и состав пароля

Введение.

На фоне многочисленных постов о паролях решил провести небольшое исследование.

В настоящее время парольная защита является самым распространённым и, к сожалению, самым ненадёжным методом защиты. Существует много статей на тему «Как составить стойкий пароль», но мне не встречались статьи, где приводятся реальные данные о надёжности паролей.

В исследовании проводится оценка надёжности паролей противостоять атакам грубой силы. Наиболее эффективный метод грубой силы при переборе паролей для хеш-функций является составление радужных таблиц.

Расчёты проводятся для трёх хеш-функций md5, sha1 и sha2 (модификация sha512). В расчёт не берутся данные о коллизиях в данных хеш-функциях, так как с практической точки зрения в реальном подборе пароля они не помогут, да и достойных реализаций в ПО на настоящий время в открытом доступе нет. В исследовании принимают участия пароли длиной 7, 8, 10 и 12 символов трёх различных алфавитов.

Для наглядности результатов приводятся данные о количестве паролей, объёме дискового пространства для хранения радужных таблиц и ориентировочном времени построения радужных таблиц.

Инструментарий.

Промежуточные расчёты.

Результаты.

Для алфавита А1

Для алфавита А2

Для алфавита А3

Для алфавита А4

Прочерк там, где программа решила, что с неё хватит подсчётов.

Выводы.

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

P.S. Это мой первый пост на хабре, сильно не пинайте, пожалуйста.

UPD Добавлен алфавит А4 и статистика к нему.

Источник

Минимальная длина пароля

Область применения

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

Справочники

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

Возможные значения

Рекомендации

Установите минимальную длину пароля как минимум до значения 8. Если количество символов установлено до 0, пароль не требуется. В большинстве сред рекомендуется использовать пароль с восемью символами, так как он достаточно длинный, чтобы обеспечить надлежащую безопасность и по-прежнему достаточно короткий, чтобы пользователи могли легко запоминать. Минимальная длина пароля, более 14, в настоящее время не поддерживается. Это значение поможет обеспечить адекватную защиту от грубой атаки силы. Добавление требований к сложности поможет уменьшить вероятность атаки словаря. Дополнительные сведения см. в статью Пароль должен соответствовать требованиям сложности.

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

Местонахождение

Конфигурация компьютера\Windows Параметры\безопасность Параметры\Политики учетной записи\Политика паролей

Значения по умолчанию

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

Управление политикой

В этом разделе описаны компоненты, средства и рекомендации, которые помогут в управлении этой политикой.

Необходимость перезапуска

Нет. Изменения в этой политике становятся эффективными без перезапуска устройства при локальном сбережении или распространении с помощью групповой политики.

Вопросы безопасности

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

Уязвимость

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

Противодействие

Настройка параметра политики минимальной длины пароля до значения 8 или более. Если количество символов установлено до 0, пароль не потребуется.

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

В некоторых юрисдикциях установлены юридические требования к длине паролей в рамках установления правил безопасности.

Возможное влияние

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

Источник

Требования к паролям — полная чушь

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

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

Пусть эта клятва будет записана на скрижалях Интернета. Я не в курсе, есть ли жизнь после смерти, но рано или поздно выясню, и тогда уж держитесь — у меня грандиозные планы.

Мир буквально погряз в ужасных правилах создания паролей:

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

Видели этот классический комикс о паролях от XKCD?

Разумеется, можно спорить, стоит ли считать «correct horse battery staple» примером хорошей стратегии для создания паролей, но суть аргумента в том, что длина решает.

Нет, серьезно, решает. Скажу даже больше: зуб даю, что ваш пароль слишком короткий. В наше время, учитывая, насколько развиты облачные вычисления и взлом паролей с помощью GPU, ставить пароль в 8 символов или короче — все равно что вообще его не ставить.

Тогда, получается, одно правило у нас уже есть: пароль не должен быть коротким. Длинный пароль с большей вероятностью окажется надежным, чем короткий… правда же?

А что скажете о таком пароле в 4 символа?

Или о таком, в 8 символов?

Или о таком, гипотетическом, но вполне реалистичном, в 7 символов?

«Извините, но ваш пароль должен содержать не менее одного символа из арабского, китайского, тайского, корейского и клингонского, пиктограмму из Wingdings и смайлик».

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

Наш старый друг Юникод опять за свое.

Как выясняется, даже простое правило «ваш пароль должен быть разумной длины» работает с оговорками. Особенно если перестать мыслить, как двинутые на ASCII американцы.

Да и если присмотреться ко всем этим славным длинным паролям… всегда ли они надежны?

aaaaaaaaaaaaaaaaaaa
0123456789012345689
passwordpassword
usernamepassword

Конечно, нет. Вы вообще видели живых пользователей в последнее время?

Они последовательно портят каждую программу, которую я создаю. Да, да, знаю, вы гики в последней стадии и знаете всё о понятии энтропии. Но выражать свою любовь к энтропии через ужасные изощренные требования к паролям вроде:

Когда мы работали над Discourse, я узнал, что окошко авторизации, оказывается, очень сложный компонент софта, несмотря на внешнюю простоту. Главное требование к паролям, которые мы приняли — длина — также было достаточно простым. Пока я писал эту статью, мы уже успели увеличить минимальную возможную длину пароля с 8 до 10 символов. А для модераторов и администраторов и решили поставить нижнюю границу еще выше, на 15 символах.

Кроме того, я настаивал на том, чтобы проверять, не совпадает ли пароль с каким-нибудь из списка 100 000 самых распространенных. Если проанализировать 10 миллионов паролей, которые попали в общий доступ из-за утечек данных, выясняется, что чаще всего используются следующие 25:

123456
123456789
qwerty
12345678
111111
1234567890
1234567
password
123123
987654321
qwertyuiop
mynoob
123321
666666
18atcskd2w
7777777
1q2w3e4r
654321
555555
3rjs1la7qe
google
1q2w3e4r5t
123qwe
zxcvbnm
1q2w3e

Даже эти данные свидетельствуют об излишней зацикленности на системе ASCII. То есть цифры-то, конечно, везде одинаковые, но мне как-то не верится, что среднестатистическому китайцу придет в голову поставить в качестве пароля «password», «quertyuiop» или «mynoob». Так что такие списки необходимо составлять с учетом локализации и прочих параметров.

(Есть еще интересная мысль: искать популярные короткие пароли в составе длинных, но, как мне кажется, получится слишком много ошибок первого рода)

Представленная статистика также свидетельствует в пользу того, чтобы делать пароли длиннее. Обратите внимание: из 25 самых популярных паролей только 5 имеют длину в 10 символов и больше. Соответственно, если мы установим минимум в 10 символов, то уже одним этим отсечем 80% списка. Впервые я это выяснил, когда собрал несколько миллионов паролей из утечек данных в рамках исследования для Discourse и отфильтровал те, которые соответствуют нашему новому требованию, чтобы длина пароля была не меньше 10 символов.

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

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

1. Требования к паролям — полная чушь

2. Установите минимальную длину пароля в Юникоде

Одно правило, по крайней мере, легко запомнить, понять и внедрить. Это то самое пресловутое правило, чтоб править всеми, оно главнее всех, сберёт всех вместе и заключит во тьме.

3. Сверяйтесь со списком самых распространенных паролей

Как я уже говорил, какие из них считать «распространенными», зависит от вашей аудитории и языка, но в любом случае, позволяя пользователям ставить пароли из списка 10 000, 100 000 или миллиона самых популярных паролей из утечек данных, вы оказываете им медвежью услугу. Нет ни малейшего сомнения, что хакер попробует эти пароли при попытке взлома, и, даже если вы ставите жесткие ограничения на количество попыток ввода, достаточно прогнать первую тысячу, чтобы добиться шокирующе хороших результатов.

Проводите исследования. Собирайте данные. Спасайте пользователей от самих себя.

4. Контролируйте количество энтропии

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

Я с некоторой грустью осознал, что нас вполне устраивает, чтобы пользователь установил пароль из 10 совершенно одинаковых символов («аааааааааа»). На мой взгляд, самый простой способ избежать такой ситуации — задать минимум в x уникальных символов на общее число y. Так мы и поступаем в последней бета-версии Discourse. Но если у вас есть какие-то другие идеи, будем рады услышать их в комментариях. Чем проще и яснее, тем лучше!

5. Отлавливайте особые типы паролей

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

Также, возможно, вам стоит блокировать еще некоторые разновидности:

Пояснение

Некоторые читатели восприняли мои слова как «все правила, кроме этих четырех, которые я сейчас распишу — полная чушь». Я имел в виду другое.

Мысль такая: сосредоточьтесь на одном ясном, простом и практичном правиле, который реально работает в любой ситуации — длине. Пользователи могут вводить что угодно (в разумных пределах) на Юникоде с одним условием — чтобы было достаточно символов. Пароль должен быть длинным — это то самое единственное собирательное правило, которому мы должны научить пользователей.

Пункты с третьего по пятый — это просто оговорки для особых случаев (типа как джину нельзя загадывать желание получить неограниченное число желаний). Тут не нужно каких-то предварительных обсуждений, потому что такие вещи должны быть редкими исключениями. Пользователей нужно останавливать, если они пытаются ввести пароль, совпадающий с именем, или 0123456789, или просто «аааааааааааа», но это должно происходить в рамках проверки данных после ввода, а не в соответствии с предварительно разъясненным правилом.

Так что, если в двух словах: правило одно — длина. Вводите что ваша душа пожелает, лишь бы количество символов тянуло на нормальный пароль.

Источник

Какова оптимальная длина пароля?

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

Вот интерфейс типичного генератора паролей:

Хороший пароль — это всё, что у вас есть, когда вас взламывают

Чтобы понять, что такое хороший пароль, посмотрим, что происходит в стане врага!

Когда вы создаёте аккаунт, сервис сохраняет пароль в одном из многочисленных форматов. Сервис может положить пароль прямо в базу данных (в виде простого текста) или сгенерировать из него хэш с помощью одного из многочисленных алгоритмов. Самые популярные:

Взлом пароля

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

И здесь важен выбор хорошего алгоритма. SHA-1 разрабатывался с учётом быстрого хэширования, это облегчает жизнь взломщикам. Bcrypt, Scrypt и Argon2 разрабатывались с учётом высоких вычислительных затрат, чтобы как можно больше замедлить взлом, особенно на специально выделенных машинах. И это очень важный аспект.

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

И не забывайте, что это зависит только от реализации сервиса, в котором вы регистрируетесь. И вы не можете узнать качество реализации. Спросить можно, но вам либо не ответят, либо отпишутся, что «мы серьёзно подходим к безопасности».

Думаете, в компаниях серьёзно относятся к безопасности и используют хорошие алгоритмы хэширования? Посмотрите на список взломанных баз данных, особенно на использованные в них хэши. Во многих случаях применялся MD5, чаще всего — SHA-1, и кое-где использовали bcrypt. Некоторые хранили пароли в виде простого текста. Такова реальность, которую нужно учитывать.

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

Пароль выбираете вы

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

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

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

Вывод: с сильным паролем вы защищены от большего количества взломов, чем со слабым паролем. А поскольку вы не знаете, насколько защищено хранилище паролей, вы не можете знать, насколько будет «достаточно безопасно» для этого сервиса. Так что предполагайте худшее, когда ваш выбор пароля ещё имеет значение.

Уникальности пароля недостаточно

Ладно, но с какой стати вам думать о том, чтобы использовать менеджер паролей и генерировать уникальный пароль для каждого сайта? В этом случае вы неуязвимы для credential stuffing — когда известная пара почтового ящика и пароля проверяется на разных сервисах в надежде, что человек использовал эти данные в разных местах. Это серьёзная угроза, потому что повторное использование паролей одна из главных проблем безопасности. От этого вас защитит генерирование уникального пароля для каждого сайта.

А если базу украдут и всё её содержимое станет известно хакерам, то зачем вам всё ещё защищать свой пароль?

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

Использование сервиса после взлома.

Как оценить силу пароля с помощью энтропии

Сила пароля характеризуется энтропией — числовым представлением количества случайности, которая содержится в пароле. Поскольку речь идёт о больших числах, то вместо 1 099 511 627 776 (2^40) нам проще сказать «40 бит энтропии». И поскольку взлом пароля — это перебор вариантов, то чем их больше, тем больше времени нужно затратить на взлом.

С длиной понятно, а что такое количество разных символов? Оно зависит от классов символов, входящих в пароль.

Например, пароль из 10 случайных строчных и прописных букв имеет log2(52 ^ 10) = 57 бит энтропии.

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

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

Руководство по энтропии

Чем больше в пароле энтропии, тем сложнее его взломать. Но сколько энтропии будет достаточно? В целом, около 16 символов будет за глаза, у такого пароля 95—102 бита энтропии, в зависимости от классов символов. А какой минимальный порог? 80 бит? 60? Или даже 102 бита слишком мало?

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

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

Национальный институт стандартов и технологий определил размеры ключей, которые будут достаточны в обозримом будущем. Там рекомендуют использовать AES-128 в период «2019—2030 и позже». Как понятно из названия, речь идёт о 128 битах энтропии.

В другой рекомендации советуют делать ключи размером не меньше 112 бит:

Для обеспечения криптографической стойкости для нужд Федерального правительства сегодня требуется не меньше 112 бит (например, для шифрования или подписи данных).

Другие соображения

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

А если использовать только буквы и цифры, то при двойном клике выделится весь пароль.

Что делать, если есть ограничение по длине? На некоторых сайтах длина пароля не может достигать 22 символов. Иногда пароли могут быть только очень короткими, например, не больше 5 цифр. Тогда остаётся только использовать пароль максимально возможной длины.

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

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

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

Заключение

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

Это защитит вас в том случае, если сервис взломают и применялся слабый, но не взломанный алгоритм хэширования.

Источник