关于这种可能性，并非所有密码都是平等的。这在很大程度上取决于我们处理的是流密码还是分组密码。

流密码（如RC4）将n 个纯文本字符流作为输入，并产生n 个加密字符流作为输出。

使用这样的密码，在密码中添加单个字符（在此处充当明文数据）将使字符上的密文更长，从而可以很好地猜测实际密码长度。

相反，块密码将仅对固定大小的块（例如AES为 128 位，这意味着 16 个字节）进行操作，最后一个块通过填充完成。

在这种情况下，在密码中添加一个字符永远不会使密文长一个字符。如果密码长度足够长以填充最后一个块（可能需要 1 到 16 个字符），则将生成一个补充密文块，但不知道这个新块实际上有多少已使用，因此没有关于确切密码长度的任何精确信息（只要涉及密码，16 个字符的近似值似乎并不可靠......）。

幸运的是，对于数据已经由有限长度的块处理的常见 TLS 应用程序，分组密码是最常用的密码。例如，HTTPS 请求具有明确的开始和结束，并且不会因分组密码导致的多达 16 个字节的填充开销而受到太大影响。因此，现在大多数 Web 服务器和浏览器更喜欢使用分组密码而不是流密码（如果流密码，主要是 RC4，没有完全禁用）。

流密码具有更有限的加密属性，它们的使用仅限于非常特定的用例，主要是数据更多地表现为流而不是定义明确的块的情况。网络级加密（例如WPA2、IPsec）是很好的例子，但这也可能影响应用级加密（例如VoIP应用可以使用SRTP，它默认依赖于流模式中使用的 AES）。在这种情况下，发送整个块来携带单个有效字节既不是最优的，也不是试图保持通信以希望更多数据来填充加密块。流密码将随着通信流继续进行。

在某些情况下，分组密码可以在流模式下使用（例如在CTR 模式下使用时）。大多数应用程序会按优先顺序显示启用的密码套件列表。此密码套件指示使用的加密算法，并在适用时附上操作模式。以下是一些密码套件示例，可以使事情更清楚：

• ECDHE-ECDSA-AES128-GCM-SHA256：这在伽罗瓦/计数器模式(GCM)中使用 AES ，这仍然是一个纯分组密码，
• ECDHE-ECDSA-AES256-SHA：这个没有明确表示操作模式，是OpenSSL的符号对应 的标准符号 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA，默认假设Cipher Block Chaining (CBC)，这也是纯分组密码，
• TLS_RSA_WITH_AES_128_CCM：这是一个标准密码套件，显示在具有 CBC-MAC (CCM) 模式的计数器中使用的 AES ，源自 CTR，它是一种使用分组密码作为流密码的方法，
• ECDH-RSA-RC4-SHA：这个不使用 AES，它使用 RC4，根据定义，它是流密码（虽然分组密码可以用作流密码，但相反的情况并非如此：您不能将流密码转换为分组密码，所以有是流密码的操作模式指示）。

这应该允许检查您的软件使用的加密类型：

• 当仅使用流密码时，可以很容易地知道加密消息的长度（因此，如果密码长度是其他已知消息的唯一变量，则很容易推断出实际密码长度，除非密码在发送之前已被散列正如 Mike Ounsworth 在他的回答中正确概述的那样），
• 仅使用分组密码会将其减少到某种近似值，可能会排除密码等小信息的任何实际用途，
• 如果您将两者相加（例如通过受 WPA（流密码）保护的 Wifi 网络访问 HTTPS（假设分组密码）网站），您将保持分组密码的优势，从而使猜测成为一个很大的近似值。

好问题。据我所知，没有通用的方法可以做到这一点，所以我很想看看其他人的帖子。我知道如果你知道协议是如何工作的，在某些情况下是可以做到的。

众所周知，加密不会隐藏消息的总长度，所以如果我知道协议，那么我可以推断出你的密码长度。

例如：假设您是其中的成员，www.someforum.com并且我知道他们的登录页面以以下形式发送登录请求：

<18 byte header> + <username> + <password> + <40 bytes of other data>

现在假设我在您登录时嗅探您的网络流量，我看到一个 83 字节长的数据包。由于我知道您的用户名是“Michael”（8 个字节，结尾为空），我可以推断您的密码是

83 - 18 - 8 - 40 = 17 bytes, with the trailing null

请注意，值得一提的登录页面（双关语）将在客户端进行几次散列迭代，因此它们发送的“密码”将始终是散列摘要，因此将具有固定长度，从而阻止这种信息泄露。