> увеличена энтропия генерируемых парольных фраз (с 42 до 47 бит по умолчанию)

крипто-куны, киньте, плиз, формулой ращота (хочу научиться щитать хаос в своих паролях).

>с 42 до 47 бит по умолчанию

неспроста

расчет энтропии

> крипто-куны, киньте, плиз, формулой ращота (хочу научиться щитать хаос в своих паролях).

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

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

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

Тем не менее, кое-какие слегка-успешные наработки на тему именно оценки энтропии произвольного пароля в битах существуют. В частности, это публикация NIST SP800-63, в ней «Appendix A: Estimating Password Entropy and Strength» (страница 46 по их нумерации или страница 56 по нумерации PDF-файла в текущей редакции - всего 8 страниц на эту тему):

http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf

А вот как их оценка коррелирует с реальной сложностью подбора паролей (конечно, это одна конкретная «атака» - другие могут давать другой результат), на основе 32 миллионов паролей, недавно утекших с RockYou:

http://reusablesec.blogspot.com/2010/01/out-of-context-graph-challenge-1.html

http://img211.yfrog.com/i/graphs.png/

(Пароли с RockYou утекли открытым текстом, так что подбирать их никому не требуется, но они очень удобны для подобных тестов - «если бы мы их подбирали, то...»)

Спасибо, здравое объяснение.

я так и знал!

Реализация индикатора «стойкости» паролей?

> Реализация индикатора «стойкости» паролей?

В passwdqc такого индикатора нет. Он пароль либо принимает, либо отвергает с кратким объяснением одной из причин.

Да, некоторые GUI-интерфейсы и веб-сайты показывают их оценку стойкости пароля во время его ввода. Возможно, будущая версия libpasswdqc будет предоставлять соответствующую функцию (умеющую выдавать промежуточные значения, а не только да/нет), но пока этого нет и спроса на это нет. Как вариант, промежуточное значение можно получить вызывая passwdqc_check() (на C/C++) или pwqcheck (из скриптов) с «ослабленными» настройками (скажем, требуемые длины в полтора раза меньше). Выдавать «красный» если она возвращает отказ, «желтый» если она пропускает пароль, но «полноценная» не пропускает, и «зеленый» если обе пропускают. Так что вообщем-то индикатор уже реализуем в приложении, использующем passwdqc.

А зачем эти велосипеды? cat /dev/urandom | base64 наше всё. Ну можно еще как-нить расширить. Там оно столько паролей вам нагенерит :3

> Одна из новых возможностей - поддержка парольных фраз, содержащих 8-битные символы (в частности, koi8-r).

Оно ещё живо? Закопайте уже!

Написали бы utf-8, было бы ничем не хуже.

Зато злобные шведы какие-нибудь не смогут подобрать твой пароль, ибо про такой кошмар как кои не слышали.

> А зачем эти велосипеды?

Это уже не велосипед, а почти автомобиль. Аналогов у него - единицы - и они принципиально хуже.

cat /dev/urandom | base64 наше всё.

А вот это как раз велосипед. Для одного сисадмина подойдет, если ему почему-то удобно запоминать кашу из символов (или записывать), но для систем с большим количеством пользователей подходит плохо - желательно позволить им выбирать такие пароли или фразы, которые им легко запоминать (в сравнении с генеренными примерно той же стойкости) - а это индивидуально. Также, «фразы», генерируемые и предлагаемые passwdqc (как один из вариантов) может быть легче запомнить, чем base64-строку. Например, pwqgen мне только что выдал nicely*Jordan2arctic.

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

Кстати, «cat» там лишний - «base64 < /dev/urandom» работает не хуже.

Вообще это я как бы чутка спетросянил, но разъяснение спасибо. Гляну чо за вещь (:

В голове нереально хранить пароли. Нужно какое-то хитрое внешнее хранилище.

А как насчет UTF-8, а koi-8r кому он сейчас вообще нужен?

Как оно теперь относится к qwerty?!

> А как насчет UTF-8

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

С точки зрения паролей (а не фраз), все символы с установленным 8-ым битом считаются одним и тем же классом (т.е., например, не будут различаться заглавные и строчные русские буквы), если только программа, использующая функции passwdqc, не вызвала setlocale() до того. Команда passwd обычно не вызывает, не говоря уже о сервисах вроде sshd, которые и вовсе запускают PAM-стек в своем контексте, до пользовательских настроек (пользователь еще только заходит). Это и хорошо и плохо. Хорошо потому что UTF-8 все равно толком «не укладывается» в существующие интерфейсы - PAM передает строки char'ов, эти char'ы преобразуются в int'ы простым дополнением нулевыми битами для передачи их в макросы ctype. Распознать что какой-то из char'ов на самом деле является частью UTF-8 символа, а этот символ еще и является, например, заглавной буквой - в общем случае нереально - то, с какой кодировкой строки мы имеем дело (UTF-8 это или вовсе нет) просто неизвестно.

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

а koi-8r кому он сейчас вообще нужен?

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

>koi8-r

Ну вот, как только о нём все забыли его начали юзать.

> Как оно теперь относится к qwerty?!

Просто сама по себе строка qwerty никогда не прошла бы умалчиваемые настройки. Существенно более сложные пароли на ее основе действительно раньше проходили - например, qWerty22 (с большой буквой и цифрами где-то кроме первой и последней позиции) раньше проходил. Теперь на него выдается «based on a common sequence of characters and not a passphrase». Кстати, 22ytr3Wq распознается аналогично (leetspeak и задом-наперед). А вот 22ytr3Wq456 - уже проходит (считается, что суммарно здесь достаточно энтропии, т.е. само по себе наличие слабой подстроки не является достаточным критерием для отказа). Всё это - с умалчиваемыми настройками. Их можно регулировать в обе стороны. 456 тоже будет слабой подстрокой если указать match=3.

>желательно позволить им выбирать такие пароли или фразы, которые им легко запоминать

Есть слоги. Рассматривая их как «цифры» получаем систему счисления по основанию равному количеству слогов. Для простого варианта слогов «согласный-гласный» русского языка преобразованием последовательности случайных чисел получаем примерно следующее:

гагябедюбезевитивабёмолафёнючылюгисюбетюсизёгюбетефёцёмэфозэвыхабепацазугибёкапомютыбепэш

В этом примере есть перерасход символов по сравнению со случайными байтами (16 бит / log2(200) = 2.09318433), так как на 200 слогов используется 2 байта, если результат хранить в однобайтовой кодировке.

Используя туже технику для латинских букв вместе с заглавными, получаем с перерасходом 16 / log2(420) = 1.836074043

LaTihudemAsoZidiWeyeWIdEMAfAfAfaqICeREfulituSOdizImUdUgerILIrOdizejaxodoRulESAfa

> Есть слоги.

Нечто подобное (для английского) реализовано в pwgen авторства Theodore Ts'o. Один из недостатков в том, что на вид «продвинутому пользователю» не очевидно, что пароль реально слабее, чем он выглядит (pwgen использует более сложную модель, чем «согласный-гласный»). Тем не менее, это неплохой подход, если длину паролей выбирать соответственно.

Сила этих типов паролей одинакова

pujilabakifavevelocu vijusurevoqorecabibu lugahezavewosiqegebe nakinudesuwurenuvibi raxakusevaqezativice

GfF4ya6.%5 ba"S%y[BE3 +;mLY4OnKs %s$`)diNqW 6JM#[a8;jI

Оба представляют собой запись случайного числа размеров в 8 байт и значит 18,446,744,073,709,551,616 вариантов.

Первый вариант вроде проще запомнить.

Точнее будет

pujilabakifavevelocu
vijusurevoqorecabibu
lugahezavewosiqegebe
nakinudesuwurenuvibi
raxakusevaqezativice

GfF4ya6.%5
ba"S%y[BE3
+;mLY4OnKs
%s$`)diNqW
6JM#[a8;jI

желательно позволить им выбирать такие пароли или фразы, которые им легко запоминать (в сравнении с генеренными примерно той же стойкости)

«I'mTh3SuperAdmin!»? Кстати, а оно может проверять «словарность» паролей?

В кои-то веки, весь тред — интересная инфа по теме. Спасибо ;)

Да ну вас. Лучшая формула - abcd123. А админы-извращенцы пусть идут к Джобсу.

> «I'mTh3SuperAdmin!»?

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

Переход от строчной к заглавной не засчитывается за начало слова сознательно - иначе слова вроде McDonald считались бы как два, а McDonald's и вовсе как три. Правда, McDonald's, O'Brien и т.п. все равно учитываются как два, а McDonald's еще и проходит как пароль (три класса символов, все разные, заглавная буква не только первая, достаточная длина). К счастью, слабых паролей такого вида мало.

Кстати, а оно может проверять «словарность» паролей?

Одна из не-основных проверок использует встроенный список из 4096 английских слов (они же используются для генерации случайных фраз). Выискиваются общие подстроки с этими словами (в том числе с трансляцией в leetspeak и/или записью задом-наперед) и вес таких подстрок снижается. Тестирование на тысячах подобранных паролей показывает, что эта проверка полезна, но играет незначительную роль - предыдущие проверки (по количеству классов символов, количеству различных, длине) гораздо важнее. В одной из будущих версий может быть добавлена поддержка внешних wordlist'ов (да, во встроенном имени Donald сейчас нет...), но это не приоритетная задача.

Вот конкретный пример:

На одном из форумов, можно найти файлы total1-Uncracked.txt и 50000_des.txt. Ссылки есть отсюда:

http://www.openwall.com/lists/john-users/2010/02/14/3

Всего было более 51,000 паролей (первый файл) - более стойких, чем «средние» - это те, которые кто-то не смог подобрать. Кто-то другой за несколько месяцев подобрал почти 24,000 из них (второй файл). Это около 47%. Берем этот список из почти 24,000 (не исключая повторы, которых там около трех тысяч) и прогоняем по нему «pwqcheck -1 --multi» с умалчиваемыми настройками. Успешно проходит проверку 661 пароль (тоже включая повторы), или около 2.8% от подобранных или 1.3% от всех. Т.е. эффективность passwdqc на этом тесте получается выше 97%. Из не прошедших проверку, лишь 238 (1% от подобранных) отвергнуто из-за «словарности» и лишь 17 из-за наличия «распространенных подстрок» (таких как qwerty или abcd). Разумеется, если бы проверка на «словарность» выполнялась первой (до других проверок), процент был бы гораздо выше (то же относится и к проверке на распространенные подстроки), но эти результаты показывают что эта проверка вообщем-то не очень важна и дальнейшее ее улучшение повлияет не сильно. Это видно из «ручного» анализа пропущенных паролей - большинство из них не «словарные», а были успешно подобраны в первую очередь из-за слабости «традиционного» crypt(3).

При использовании bcrypt или phpass, результат был бы намного лучше:

http://www.openwall.com/crypt/

http://www.openwall.com/phpass/

Для тестирования поддержки фраз требуются другие файлы (без ограничения длины). Такие тесты я тоже проводил. Процент подбираемых, но проходящих проверки, для «сырого» MD5 (пароли старых/глупых веб-приложений) выходит близкий к названному выше, тогда как для bcrypt и phpass он гораздо ниже.