suCipAytAyswed0
LUnhefcerAnAcg2
it2drosharkEweo
UndosnAiHigcir0
AKDySwaybficMi5
DorrIfewfAidty5
MeecradGosdovl9
KasEsacHuhyflo4
OngouHemNikEyd0
在所有这些密码中，只有一位数字，除了第三位数字数字在末尾。我使用这种确切的模式获取大量密码的机会非常低，而且我在Chrome生成的其他密码中也看到过这种密码，因此，我相信如果生成更多密码，密码还会继续使用。
这似乎很奇怪，将密码生成为随机的字母和数字集合比强制执行某种奇怪的模式难道不是一件容易的事吗？鉴于这些不应该被记住？ Chrome为什么还会做其他事情？
#1 楼
Conor的答案是一个很好的起点，但是，如果您深入研究Chromium的来源，情况似乎会变得有些黯淡（但总比不使用密码管理器要好）。Chrome 68（当前版本）截至2018年8月1日）。
从68版开始，Chrome遵循FIPS 181生成15个字符的可发音密码，允许使用大写字母，小写字母和数字。如果结果不同时包含大写字母和数字，则会将第一个小写字母更改为大写字母，并将最后一个小写字母更改为随机数字。
不幸的是，FIPS 181的熵密码很难计算，因为它生成可变长度的音节而不是字符，并且有很多规则规定是否允许音节。
非均匀性具有严重的含义。 1994年的一篇论文（第192页）估计，要想在100个拥有8个字符密码的帐户中闯入1个，攻击者只需要尝试160万个密码即可。即使将长度从8增加到15会使熵加倍，但平均而言熵仍可能低于60位1，尽管由于大写字母而有所改善。
原始标准似乎不支持大写字母或数字，并且Implementation2仅以50％的机会将音节的第一个字母大写（有趣的是，在所检查的字符数组中，
y被w取代，因此y永远不会大写）。这意味着大写字母不是每个字母增加1位熵，而是每个音节仅增加1位熵。音节的数量不是恒定的，因此很难确定它实际上增加了多少熵，但是鉴于单字母音节的稀缺性，几乎可以肯定平均增加了不到8位。通过将每个单个字母音节交替转换为数字或符号的可能性达到50％，以支持数字和符号（尽管未使用符号功能）。不幸的是，正如您所注意到的，单字母音节并不常见3，因此
ForceFixPassword通常最终会将最后一个小写字母换成一个数字。看着它。简而言之，这不是一种非常好的生成密码的方法，并且熵远小于预期的长度。在实践中，这对于普通用户而言仍然可以接受，因为这意味着他们不会在20个不同的地方使用他们喜欢的低熵密码，但是对于具有快速哈希值的坚定且有资金的攻击者来说，破解它绝对是可能的（即Chrome 69（计划于9月发布）。
Chrome 69看起来情况要好得多。字符集大小写字母，数字和符号
-_.:!，为便于阅读，删除了以下内容：l（小写字母L）I（大写字母i ）1（数字1）O（大写字母o）0（数字零）o （小写字母O）生成通过在每个类中添加一个随机字符直到达到该类的最小计数来进行。默认情况下，当前使用的是一个小写字符，一个大写字符和一位数字。
然后其余的密码填充有从所有字符类中均匀选择的随机字符（尊重最大数量）对于每个类，当前未使用。）
最后，由于为了满足要求，从可预测的类中将字符添加到了密码的开头，所以该字符串被随机地改组。如果相邻两个破折号或下划线以提高可读性，则重排最多发生5次，因此这将极大地减少熵，但是减少幅度很小，以至于不明显（从允许的符号中删除破折号或下划线会更糟）。
使用61个可能的字符，一个完全随机的密码将具有log2（6115）= 88.96位的熵。使用包含-排除来说明所需的字符，我得出了88.77位的熵：
61^15 all possible passwords
-53^15 passwords without digits 2-9 (0 and 1 are excluded)
-37^15 passwords without lowercase letters (l and o excluded)
-37^15 passwords without uppercase letters (I and O excluded)
+29^15 add back passwords excluded twice for lack of digit and lowercase
+29^15 add back passwords excluded twice for lack of digit and uppercase
+13^15 add back passwords excluded twice for lack of lowercase and uppercase
-5^15 remove all-symbol passwords that were excluded then added back
多余的混洗也将减少一小部分，但我现在没有时间进行计算。最后，密码应该具有88位以上的熵，这非常好。
旧的生成器仍存在于版本69中，但是当我测试开发版本时，它正在使用新的生成器。是否有任何方法可以使用我不知道的旧生成器。
1。平均熵对非均匀分布不一定有用，原始的1975年论文给出了一个生成器的示例（第29-30页），该生成器生成单个密码（例如“密码”）的可能性为50％，且熵高否则输入密码。平均熵可能很高，但是仍有50％的机会会立即猜出密码。即便如此，从1994年的分析中推断，我认为在最坏的情况下，它仍然应该有超过40位。
2。该实现实际上不是Chrome的实现，而是取自APG程序，并做了一些小的改动以实现兼容性
3。使用
apg进行的测试表明，单字母音节实际上出现在大约33％的密码中，但是其中70-75％的密码最后只包含一个单音节。评论
数学上的出色工作，并且对此答案表示赞同，但我真的认为“黯淡”夸大了这个问题。您要添加“仅” 30位的熵。从字面上看，这仍然使猜测密码的难度提高了大约10亿倍。我会说这还远非完美，但是除了使用泄漏的密码哈希进行的离线攻击之外，您什么都可以避免。而且，即使密码在脱机攻击中受到破坏，他们也不能使用相同的密码来闯入其他站点，因为该密码不会在其他站点上重复使用。
–帕特里克M
18年8月1日在21:58
@PatrickM是的，我正在考虑添加更多有关普通用户仍然可以接受的方法。由于很难计算出不均匀的密码分布，因此我实际上并不确定它的熵超过50位，但这仍然比密码要差得多的人更好。
– AndrolGenhald
18年8月1日在22:00
应该指出的是，40比特的熵虽然对于生成的密码来说是低的，但仍可能比用户选择的密码好几个数量级，因为许多用户可能会选择“秘密”或“密码”之类的东西。
–sleske
18年8月3日在9:48
#2 楼
让我从一个重要而准确的警告开始：http://dilbert.com/strip/2001-10-25
数学
看看实际的赔率，有62个可能的字符（a-zA-Z0-9），因此假设所有字符均等分布，这意味着任何给定字符都有〜16％的概率成为数字。
您总共给我们展示了136个字符，这意味着应该有〜21位数字，而不是您显示的9位数字。通过1000次随机试验，我得到的平均值为21.5位，标准差为4.3。这意味着只有9位数字的136个字符串大约是3sigma离群值（由于随机几率的影响只有0.3％的变化）。当然，这假定您没有任何示例，而您的示例中遗漏了更多的数字。
结论
，这表明缺少数字不仅仅是随机的。这可能意味着两件事：要么google使用的密码生成算法只是在末尾加一个数字，要么他们的密码生成算法或熵的来源有问题。如果不查看其来源，很难说出其中哪种情况更有可能。当然，这并不简单，只是在末尾加一个数字，因为您有一个示例，其开头是一个数字。因此，如果这是他们的密码生成算法的故意结果，那么他们的算法就很奇怪，这让我觉得还有其他事情发生。
根据上述Per Androl的回答，Chrome的密码生成算法确实在做一些非常奇怪的事情。 。
答案
当然，这些都不能回答您的实际问题：这些密码是否具有足够的熵？忽略未知随机性的数字，我们至少可以将其视为一串长度为14的随机字母。这样的字符串（假设它们使用的是良好的CSPRNG）将具有1.06e24的可能值，或〜80位的熵。为了进行比较，由字母或数字组成的15个字符长的字符串将具有〜90位的熵。那是“足够的”熵吗？好吧，这是一个很难回答的问题。这取决于-密码是否存储在使用md5并泄漏其数据库以进行离线破解的网站上？它是否存储在以纯文本存储密码的网站上（在这种情况下，熵的大小无关紧要）？对于一个采用现代最佳实践来保护密码的网站，情况又如何呢？此答案给出了一个有用的比较，并建议对于普通的sha256而言，具有80位熵的密码实际上不可破解（有很多警告）：
https://security.stackexchange.com/a/168511/149676
因此，我要说的是，即使密码分配不正确，密码的长度也足够长，以至于在可预见的将来，信息熵还足够。
评论
我可以告诉您，即使使用像MD5这样的“弱”哈希，用于蛮力攻击的密钥空间也实在太大。即使我们假设只有一位并且总是在结尾，那仍然是（52 ^ 14）* 10的组合。即使以每秒1万亿的哈希值计算，仍然需要数以千计的时间才能破解。
–拉玛先生
18年8月1日在17:53
@拉玛先生确实。我只是试图使想法变得“高”或“足够”熵可能是特定于上下文的。
– Conor Mancone
18年8月1日在17:58
进一步了解的唯一方法可能是深入研究Chromium的代码，但是我的C ++不够好，无法找到生成密码的代码。
– gngdb
18年8月1日在18:13
你的数学错了。 OP并未预测每个密码有一个数字，而是追溯了一种模式。这就像在说：“恰好在这一刻，这种人类蜜蜂的组合还活着的机会有多少？”。 100％。如果足够努力，人们总会找到一种模式。追溯说“这不太可能”是错误的数学。
– DonQuiKong
18年8月2日在11:40
@DonQuiKong“这不太可能”是唯一正确的数学方法。我计算了这样的几率，即假设数字和字母是均匀分布的，那么许多密码只有一位数字，表明几率很低（〜0.3％），因此得出的结论是“不太可能”。对Arnhold的进一步挖掘表明，实际上密码不是由均匀分布的字母和数字组成的。我了解人们很擅长找到模式（实际上，我对此站点有评论和回答），但是在这种情况下，确实有其背后的含义。
– Conor Mancone
18年8月2日在12:55
#3 楼
您的问题中有两个错误的假设，这些答案导致了为什么Chrome生成这样的密码而不是p ^＆7 + 4 + {ZgfnP＃P /。的答案，首先，您假设密码不应该被记住，因此应该是完全随机的。他们不是。 Chrome与许多随机密码生成器一样，会创建发音密码，如AndrolGenhald的答案中所述。例如手机，并使其更容易记住。您为什么认为不记得Chrome密码？如今，只有很少的人仅用一台设备访问Internet。
其次，您认为密码需要很复杂。这是一个常见的误解，已经被人篡改了许多次，最正式的误解是撤销了NIST SP-800中的复杂性建议（例如，请参见https://www.passwordping.com/surprising-new-password-guidelines- nist /）。
密码尤其应该很长。 Chrome可以很好地满足这一条件（对于非关键Web应用程序，当前推荐的最低字符数是12个字符）。
鉴于这些事实，Chrome生成的密码符合良好的现代密码标准。可以讨论改进，并且肯定是可能的，但是改进肯定在正确的轨道上。
评论
您是否有至少12个字符的参考？看来合理，但似乎并未得到广泛讨论。我可以找到的少数几个推荐的最低标准是cnil.fr/sites/default/files/atoms/files/…第一部分，第1小节，案例1（PDF第3页）。
–用户
18年8月2日在9:38
我的脑海里没有参考。目前的讨论十分广泛，有太多人仍旧停留在Astrologie尚未死的旧方式上。确切的长度取决于您的情况和威胁分析，12只是一个合理的总括数。有人建议使用16甚至20。这听起来很长，但是如果您不允许人们使用常规字词或短语而不是乱七八糟的东西，那么实际上就不是这样，以便他们可以使用常规打字速度（这会使肩膀冲浪更加困难，等等）。
–汤姆
18年8月2日在11:58
我也不知道Chrome正在生成本来值得记住的密码。但是，如果您有一堆这样的密码，我会挑战任何人，以记住哪个密码与哪个网站一起使用。它们只是勉强发音，没有助记符将它们联系起来。我认为大多数人都需要依赖密码管理器。
– Barmar
18年8月2日在13:33
也许我只是不习惯它们，但是我发现Chrome密码就像20个字符的统一随机字母数字密码一样容易记住（即，直到大约一周后才输入）
–timuzhti
18年8月3日在4:14
#4 楼
请注意，这只是我的一种猜测，但这可能是为了使密码更易于记忆和/或转录为密码输入框。除了奇数编号之外，我还注意到提供的示例似乎很明显，而且我看到其他密码生成器也做了类似的操作（例如，LastPass可以选择将生成的密码设为“易于说”）。有一些公开的算法可以做到这一点（例如https://exyr.org/2011/random-pronounceable-passwords/）。使它们清晰可辨，并且看似非随机的数字位置显然可以减少熵，但在不知道实际使用的算法的情况下，无法说出多少。 Chrome开发人员可能已经评估了生成的熵，并决定可用性的好处超过了丢失的熵，而剩余的熵仍然相对安全。
评论
你能繁殖吗？还是只尝试过一次？不随机生成数字密码的原因可能是由于许多网站要求密码至少包含1位数字。