Почему этот случайный пароль помечен, говоря, что он слишком упрощенный / систематический?

Как случайная строка M1uG*xgRCthKWwjIjWc*010iSthY9bucопределяется как слишком упрощенная / систематическая для пароля в соответствии с passwd и cracklib-check ? Попробуйте на своей машине и посмотрите

echo "M1uG*xgRCthKWwjIjWc*010iSthY9buc" | cracklib-check

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

Поскольку cracklib является открытым исходным кодом, ответ можно найти в исходном коде .

«Слишком упрощенный / систематический» означает, что существует слишком много символов, которым предшествует один из их алфавитных соседей. Следовательно, "ab" или "ba" считаются плохими, но "ac" или "ca" в порядке, поскольку b опущено.

До этого патча от 2010-03-02 , он допускает не более четырех персонажей, которые проявляют эту черту. Например, «bar12345» потерпит неудачу, потому что символы «a», «2», «3», «4» и «5» являются алфавитными соседями предыдущих символов.

Слм узнал в своем ответе, что M1uG*xgRCthKWwjIjWc*010iSвсе в порядке, а M1uG*xgRCthKWwjIjWc*010iStпока нет. Давайте проанализируем. Вот символы, которые считает cracklib-check указанием на системный пароль:

M1uG*xgRCthKWwjIjWc*010iS
               ^^    ^^

который ниже максимума четырех, но добавив т:

M1uG*xgRCthKWwjIjWc*010iSt
               ^^    ^^  ^

толкает его выше предела, так как T следует за S (кажется, что тест нечувствителен к регистру).

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

На Fedora 19

Когда я запускаю его, я в порядке. Я на Fedora 19.

$ echo 'M1uG*xgRCthKWwjIjWc*010iSthY9buc' | cracklib-check
M1uG*xgRCthKWwjIjWc*010iSthY9buc: OK

Вот информация о версии:

$ rpm -qfi /usr/sbin/cracklib-check | grep -E "Version|Release"
Version     : 2.8.22
Release     : 3.fc19

ПРИМЕЧАНИЕ: я бы попробовал сделать это с одинарными кавычками, а не с двойными, так как вы имеете дело с ними *, они могут быть странным образом расширены для вас.

CentOS 5 & 6

Попробовать ваш пример на CentOS 6 было хорошо, получил ОК, но он потерпел неудачу, как вы описали на CentOS 5.9.

$ echo 'M1uG*xgRCthKWwjIjWc*010iSthY9buc' | cracklib-check
M1uG*xgRCthKWwjIjWc*010iSthY9buc: it is too simplistic/systematic

Информация о версии:

$ rpm -qfi /usr/sbin/cracklib-check | grep -E "Version|Release"
Version     : 2.8.9                  
Release     : 3.3

Жук?

То, с чем вы столкнулись, может показаться ошибкой. Если вы возьмете свою строку и введете в cracklib-checkнее все больше и больше строк, вы заметите, что когда вы доберетесь до 26-го символа, он начнет давать сбой:

# 25    
$ cracklib-check <<<"M1uG*xgRCthKWwjIjWc*010iS"
M1uG*xgRCthKWwjIjWc*010iS: OK

# 26
$ cracklib-check <<<"M1uG*xgRCthKWwjIjWc*010iSt"
M1uG*xgRCthKWwjIjWc*010iSt: it is too simplistic/systematic

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

$ cracklib-check <<<"M1uG*xgRCthKWwjIjWc*010iSvhY9b"
M1uG*xgRCthKWwjIjWc*010iSvhY9b: OK

Так что казалось бы, что в версии cracklib-checkзацикливается на подстроке Sth.

В кусках строки, которую вы предоставили, определенно есть что-то странное. Если я возьму концевую часть хвоста и пропущу переднюю часть, я также могу заставить эту часть потерпеть крах.

$ cracklib-check <<<"jIjc*010Sth"
jIjc*010Sth: it is too simplistic/systematic

Эта же строка вызывает проблемы в Fedora 19 и CentOS 6!

На основе @ Waxwing - х очень хорошие слежки, теперь мы знаем , что эвристика используется получала подножку , если> 4 -х символов были слишком рядом друг с другом. Патч был введен , который изменил эту эвристику , так что общая длина пароля рассматриваемого учитывалась для устранения этих ложных срабатываний.

Выводы?

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

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

Или, по крайней мере, я бы предложил перейти на более новую версию, которая включает исправления, которые @maxwing упоминает в своем ответе.

Пароль Gen Альтернативы

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

$ pwgen -1cny 32
iWu0iPh8aena9raSoh{v6me)eh:eu6Ei

Вы также можете использовать небольшую магию сценариев tr, /dev/urandomи foldполучить очень качественный случайный пароль.

$ tr -dc '[:graph:]' </dev/urandom | fold -w 32 | head -n 1
;>$7\`Hl$=zn}R.b3h/uf7mY54xp}zSF

Команда foldможет контролировать длину. В качестве альтернативы вы можете сделать это тоже:

$ echo $(tr -dc '[:graph:]' </dev/urandom | head -c 32)
/_U>s[#_eLKAl(mrE@oo%X~/pcg$6-kr