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?
-
1I suppose that such kind of leak would be greatly diminished by the use of block ciphers, which is now quite a standard for most TLS uses. – WhiteWinterWolf Aug 13 '15 at 13:25
-
2@WhiteWinterWolf Can you explain further how block ciphers hide the length of the input message? That does't seem like an obvious statement. – Mike Ounsworth Aug 13 '15 at 13:48
-
@MikeOunsworth: You can see my new answer then :) – WhiteWinterWolf Aug 13 '15 at 14:38
-
Right, so without knowing how much padding was added, you can only deduce the length of the password up to the closest block. Fair. – Mike Ounsworth Aug 13 '15 at 17:20
2 Answers
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 notationTLS_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.
![](../../users/profiles/32746.webp)
- 19,082
- 4
- 58
- 104
-
Interesting, but I read that in TLS 1.2, there is a CCM mode of operation (https://en.wikipedia.org/wiki/CCM_mode). Quote 'CCM is effectively a stream cipher'. So in this mode it would be possible to guess the length? Reading further, this would mean that in WPA2 and IPSEC the length could be guessed? – Michael Aug 13 '15 at 14:53
-
@Michael: I have completed my answer, do not hesitate to tell me if it does not fully answer your questions or you still have some remaining doubts :). – WhiteWinterWolf Aug 13 '15 at 16:26
-
Thanks, so cross-linking to http://security.stackexchange.com/questions/76993/now-that-it-is-2015-what-ssl-tls-cipher-suites-should-be-used-in-a-high-securit , this attack would almost never work in practice (if the server is configured well of course). – Michael Aug 14 '15 at 09:19
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.
![](../../users/profiles/61443.webp)
- 57,707
- 21
- 150
- 207
-
`Note that login pages that are worth their salt (pun intended) will do a couple iterations of hashing on the client side` wouldn't that require server to store password in the plaintext? – Cthulhu Aug 13 '15 at 15:10
-
2@Cthulhu No, not at all, good login pages will do some hashing client-side to offload some computation, and to prevent the server from ever seeing the plaintext pwd, and then a bigger round of hashing server-side to protect against rainbow table attacks. Do both. [Here's an answer I recently gave on this topic.](http://security.stackexchange.com/a/96556/61443) – Mike Ounsworth Aug 13 '15 at 15:17