为什么这个随机密码被标记为过于简单化/系统化？

Question

M1uG*xgRCthKWwjIjWc*010iSthY9buc根据passwd和cracklib-check ，如何将随机字符串检测为过于简单/系统化的密码？在你的机器上试试看

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

请注意，这不是我的密码，而是来自同一个随机密码生成器的另一个随机生成的字符串，它产生相同的结果。

Answer 1

由于cracklib是开源的，答案可以在源代码中找到。

“过于简单化/系统化”意味着有太多字符前面是它们的字母邻居之一。因此，“ab”或“ba”被认为是坏的，但“ac”或“ca”是可以的，因为 b 被省略了。

在2010-03-02 的这个补丁之前，它最多允许四个字符表现出这个特性。例如，“bar12345”会失败，因为字符“a”、“2”、“3”、“4”和“5”是前面字符的字母邻居。

slm 在他的回答中发现没问题M1uG*xgRCthKWwjIjWc*010iS，但M1uG*xgRCthKWwjIjWc*010iSt不是。我们来分析一下。以下是cracklib-check认为是系统密码指示的字符：

M1uG*xgRCthKWwjIjWc*010iS
               ^^    ^^

这低于最大值四，但添加了 t：

M1uG*xgRCthKWwjIjWc*010iSt
               ^^    ^^  ^

将其推到极限以上，因为 T 跟在 S 之后（看起来测试不区分大小写）。

该补丁更改了最大限制，因此它取决于总密码长度，以避免像这样的误报。

Answer 2

在 Fedora 19 上

当我运行它时，我就OK了。我在 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

注意：我也会尝试使用单引号而不是双引号，因为您正在处理*'s 它们可能会以奇怪的方式在您身上扩展。

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 出现问题！

更新 #1

基于@waxwing非常好的侦查，我们现在知道，如果 > 4 个字符彼此太相邻，则使用的启发式方法会被绊倒。引入了一个补丁来更改此启发式方法，以便考虑所考虑的密码的总长度以消除这些误报。

结论？

根据我的一些有限测试，这里似乎有一些奇怪的启发式方法。某些看似没问题的字符串正在绊倒它。

如果您想对此进行编纂，我建议您包装密码的生成和评估，然后在生成可以满足的密码后跳出循环cracklib-check。

或者至少我建议升级到更新的版本，其中包含@maxwing 在他的回答中提到的修复程序。

密码生成替代品

pwgen

我还要补充一点，我通常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