Is it possible to guess the length of a password by sniffing TLS packets?

Question

In this answer, the author states that it is possible to tell the length of your password, by sniffing your TLS packets. Is this true, and how would this be done in practice?

Answer 1

All ciphers are not made equal regarding this possibility. It greatly depends whether we are dealing with a stream cipher or a block cipher.

Stream ciphers (like RC4) take a flow of n plain-text characters as input and produce a flow of n encrypted characters as output.

With such ciphers, adding a single character to the password (which acts as the plaintext data here) will make the cipher text on character longer, thus allowing a really good guess on actual password length.

Block ciphers, on the opposite, will only operate on blocks of fixed size (128 bits for AES for instance, which means 16 bytes), the last block being completed with padding.

In such case, adding a single character to the password will never make the cipher text one character longer. If it happens that the password length is long enough to fill the last block (it may require from 1 to 16 characters) then a supplementary block of cipher text will be produced, but with no mean to know how much of this new block is actually used, and therefore without any precise information about the exact password length (a 16 characters approximation does not seems reliable as long as passwords are concerned...).

Fortunately, block ciphers are the most used ciphers for common TLS applications where the data is already handled by blocks of finite length. An HTTPS request for instance has a clear begin and end and do not suffer that much from the up-to 16 bytes padding overhead caused by block ciphers. Therefore, most web servers and browsers nowadays prefer to use block ciphers than stream ones (if stream ciphers, RC4 mainly, are not disabled altogether).

Stream ciphers, having more limited cryptography properties, see their usage being restricted to very specific use-cases, mainly situations where the data appears more as a flow than well defined blocks. Network level cryptography (WPA2, IPsec for instance) are good example, but this may also affect application-level cryptography as well (VoIP application for instance can use SRTP which relies by default on AES used in stream mode). In such cases it would neither be optimal to send a whole block to carry a single effective byte nor to try to hold-on the communication in the hope that more data will come to fill the cryptographic block. A stream cipher will just follow the communication flow as it goes on.

Under some conditions, a block cipher can be used in stream mode (when used in CTR mode for instance). Most applications show a list of the enabled cipher suites in their order of preference. This cipher suites indicates the encryption algorithm used, accompanied by the operation mode whenever applicable. Here are a few cipher suite examples to make things clearer:

• ECDHE-ECDSA-AES128-GCM-SHA256: This uses AES in Galois/Counter Mode (GCM), this remains a pure block cipher,
• ECDHE-ECDSA-AES256-SHA: This one does not clearly show an operation mode, it is an OpenSSL notation corresponding to the standard notation TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA assuming Cipher Block Chaining (CBC) by default, this is also a pure block cipher,
• TLS_RSA_WITH_AES_128_CCM: This is a standard cipher suite showing AES used in Counter with CBC-MAC (CCM) mode, derived from CTR it is a way to use a block cipher as a stream one,
• ECDH-RSA-RC4-SHA: This one does not use AES, it uses RC4 in place which is by definition a stream cipher (while block cipher can be used as stream ones, the opposite is not true: you cannot turn a stream cipher into a block one, so there is operation mode indication for stream ciphers).

This should allow to check the kind of encryption used by your software:

• When using only stream cipher, the length of the encrypted message can be easily known (so if the password length is the only variable of an otherwise known message it becomes easy to deduce the actual password length, unless the password has been hashed before being sent as Mike Ounsworth rightly outlines in his answer),
• Using only block cipher will reduce this to some approximation, possibly excluding any practical use for such a small information as a password,
• If you cumulate the two (for instance accessing an HTTPS (assuming block cipher) website over a WPA (stream cipher) protected Wifi network) you keep the advantage of the block cipher making the guessing a large approximation.

Answer 2

Good question. As far as I know, there's no general way to do it, so I'm curious to see what others post. I know that it is possible to do in some cases if you know how the protocol works.

It's well known that encryption does not hide the overall length of the message, so if I know the protocol then I can deduce the length of your password.

For example: let's say that you're a member of www.someforum.com and I know that their login page sends login requests in the following form:

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

Now let's say I sniff your network traffic while you're logging in and I see a packet which is 83 bytes long. Since I know your username is "Michael" (8 bytes with the trailing null), I can deduce that your password is

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

Note that login pages that are worth their salt (pun intended) will do a couple iterations of hashing on the client side, so the "password" they send will always be a hash digest and therefor will have a fixed length, thwarting this kind of information leak.