Conor 的回答是一个很好的起点，但是如果您深入研究 Chromium 的源代码，情况就会开始变得有些暗淡（但总比完全不使用密码管理器要好）。

Chrome 68（截至 2018 年 8 月 1 日的当前版本）

在 68 版之前，Chrome 遵循 FIPS 181 生成 15 个字符的可发音密码，允许使用大写字母、小写字母和数字。如果结果不包含大写字母和数字，它将第一个小写字母更改为大写，并将最后一个小写字符更改为随机数字。

不幸的是，FIPS 181 密码的熵很难计算，因为它生成可变长度的音节而不是字符，并且有很多规则规定是否允许使用音节。

这种不均匀性具有严重的影响。1994 年的一篇论文（第 192 页）估计，要想破解 100 个具有 8 个字符密码的帐户中的 1 个，攻击者只需尝试 160 万个密码。即使将长度从 8 增加到 15 会使熵加倍，这仍然可能平均低于 60 位的熵¹，尽管由于大写，这略有改善。

原始标准似乎不支持大写字母或数字，并且实现²仅以 50% 的机会将音节的第一个字母大写（有趣的是在检查的字符数组y中替换为，因此永远不会大写）。这意味着不是每个字母增加大约 1 位熵，而是每个音节只增加 1 位。音节的数量不是恒定的，因此很难确定这实际上增加了多少熵，但鉴于单个字母音节的稀缺性，几乎可以肯定它平均增加了不到 8 位。wy

通过将每个单个字母音节交替转换为数字或符号来支持数字和符号，有 50% 的机会（尽管未使用符号功能）。不幸的是，正如您所注意到的，单字母音节并不常见³，因此ForceFixPassword通常最终将最后一个小写字母换成数字。

可能还有更多问题，但我有点厌倦了看它。简而言之，这不是一种很好的密码生成方法，而且熵明显低于人们对长度的预期。实际上，这对于普通用户来说可能还是可以的，因为这意味着他们不会在 20 个不同的地方使用他们最喜欢的低熵密码，但是对于一个坚定且有资金的攻击者来说，使用快速哈希（即不是一个好的密码哈希) 的密码。

Chrome 69（计划于 9 月发布）

Chrome 69 中的情况看起来好多了。字符集是大写和小写字母、数字和符号，为了便于阅读，删除-_.:!了以下内容：

• l （小写字母 L）
• I （大写字母 i）
• 1 （数字一）
• O （大写字母 o）
• 0 （数字零）
• o （小写字母 O）

生成的工作原理是从每个类中添加一个随机字符，直到满足该类的最小计数。默认情况下和当前使用的是一个小写字符、一个大写字符和一个数字。

然后密码的其余部分用从所有字符类中均匀选择的随机字符填充（考虑每个类的最大计数，当前未使用）。

最后，由于从可预测的类中将字符添加到密码的开头以满足要求，因此字符串被随机打乱。如果两个破折号或下划线相邻以提高可读性，则改组最多发生 5 次，因此这将略微降低熵，但减少是如此轻微以至于不明显（并且从允许的符号中删除破折号或下划线会更糟）。

对于 61 个可能的字符，完全随机的密码将具有 log ₂ (61 ¹⁵ ) = 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% 的密码末尾只有一个字母音节。}

让我从一个重要而准确的警告开始：

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% 的变化）。当然，这假定您没有任何示例中没有包含更多数字的示例。

结论

这表明缺乏数字不仅仅是随机的。这可能意味着几件事：要么谷歌使用的密码生成算法只是在末尾加上一个数字，要么他们的密码生成算法或熵源有问题。如果不查看他们的来源，很难说哪些情况更有可能。当然，这并不像在末尾添加一个数字那么简单，因为您有一个示例，开头是一个数字。所以如果这是他们的密码生成算法的故意结果，那么他们的算法很奇怪，这让我觉得还有别的事情发生。

更新上面 Per Androl 的回答，chrome 的密码生成算法确实在做一些很奇怪的事情。

答案

当然，这些都不能回答您的实际问题：这些密码是否有足够的熵？忽略未知随机性的数字，我们至少可以将其视为一串长度为 14 的随机字母。这样的字符串（假设他们使用的是好的 CSPRNG）将有 1.06e24 个可能的值，或约 80 位熵。为了比较，由字母或数字组成的 15 个字符长的字符串将具有约 90 位的熵。那是“足够”的熵吗？嗯，这是一个更难回答的问题。这取决于 - 然后该密码是否存储在使用 md5 并泄露其数据库以进行离线破解钻机的网站上？它是否存储在以纯文本形式存储密码的网站上（在这种情况下，熵的大小无关紧要）？使用现代最佳实践保护您的密码的网站怎么样？这个答案提供了一个有用的比较，并表明对于普通的 sha256，具有 80 位熵的密码实际上是不可破解的（有很多警告）：

https://security.stackexchange.com/a/168511/149676

因此，我会说即使他们没有正确随机化数字，密码也足够长，以至于在可预见的未来有足够的熵。

您的问题中有两个错误的假设导致了为什么 Chrome 会生成这样的密码而不是 p^&7+4+{ZgfnP#P/.

首先，您假设密码不应该被记住，因此应该是完全随机的。他们不是。与许多随机密码生成器一样，Chrome 会创建可发音的密码，如 AndrolGenhald 的回答中详细概述的那样。

使用可发音的密码而不是乱码可以减少输入错误，例如，允许通过电话将密码传递给其他人，并且更容易记住密码。为什么您认为不应记住 Chrome 密码？如今，很少有人只用一台设备访问互联网。

其次，您假设密码需要很复杂。这是一种常见的误解，已被多次伪造，最官方的误解是撤销 NIST SP-800 中的复杂性建议（参见例如https://www.passwordping.com/surprising-new-password-guidelines-尼斯特/ )。

最重要的是，密码应该很长。Chrome 很好地满足了这个条件（12 个字符是当前非关键 Web 应用程序的最低推荐值）。

鉴于这些事实，Chrome 生成的密码符合良好的现代密码标准。可以讨论改进并且肯定是可能的，但它们肯定是在正确的轨道上。

请注意，这只是我的猜测，但这可能是为了使密码更容易记住和/或转录到密码输入框中。除了奇数位置之外，我注意到提供的示例似乎大多是可发音的，而且我看到其他密码生成器做了类似的事情（例如LastPass 可以选择使生成的密码“容易说”）。有公共算法可以做到这一点（例如https://exyr.org/2011/random-pronounceable-passwords/）。

使它们可发音并具有看似非随机的数字位置显然会减少熵，但在不知道实际使用的算法的情况下，不可能说出多少。Chrome 开发人员可能已经评估了生成的熵，并认为可用性收益超过了损失的熵，并且剩余的熵仍然相对安全。