Skip to main content
11 events
when toggle format what by license comment
Jun 25, 2015 at 9:04 comment added Steve Jessop @prakharsingh95: Tom's point is that there are too many different ways that it might leak. Even if you could plug this one leak of many, it still doesn't allow you to rely on the secrecy of the password length. For HTTPS in general, sure, mixing up the lengths a bit might throw some chaff and prevent some of its simpler information leaks. For example if you have a website serving 10,000 documents all of different lengths, you might seriously look at the implications of an attacker deducing which of those documents each visitor views.
Jun 25, 2015 at 8:45 comment added xyz @SteveJessop Indeed. I had made the advertisement point in general HTTPS content length. It seems that adding some random padding into the POST content from client will prevent these side channel attacks (or hashing the password on client side).
Jun 25, 2015 at 8:34 comment added Steve Jessop @prakharsingh95: user names probably aren't secret at the point where someone is trying to crack your password (but, if the username is unknown to the attacker, then you're right it will confound attempts to determine password length from the size of the https post request used to log in). CSRF tokens are usually fixed length for a given site, and the attacker can determine this length just by using the site, but there are no doubt some exceptions. https requests from the user to the server don't typically contain advertisements.
Jun 24, 2015 at 20:12 comment added Ben Voigt @david: Yes, leaking time between keypresses is a serious disclosure, there's a lot of mutual information there.
Jun 24, 2015 at 18:06 comment added xyz @TomLeek you're missing one key point. Additional data like user names, CSRF tokens, and advertisements etc will change the content length. It's useless to listen to such traffic in such cases. Also, some sites compute bcrypt on client side itself (not sure), thus abstracting length from the request data.
Jun 23, 2015 at 21:39 comment added Ernie I think that telling anyone trying to brute force your password that you have a password 17 characters long would be sufficient to discourage them from even attempting to brute force your password at all, and find another flaw in your security. So there'd be significant time savings for them. ;)
Jun 23, 2015 at 20:16 comment added AviD The total amount of entropy provided the by password length is not too difficult to calculate, or rather the MAXIMUM entropy... let's assume passwords can be any length between 1 character and 32, then it is 5 bits of entropy at most, with of course a heavy bunching down near the bottom by the minimum required length. Of course, some banks will restrict you to 12 characters (minimum 6), so that's only 2.5 bits AT MOST. All that is of course assuming that the length is secret, which its not...
Jun 23, 2015 at 20:05 comment added Tom Leek Modern fashion with TLS is to use AES/GCM cipher suites, where there is no padding -- the plaintext length can thus be inferred with the utmost precision.
Jun 23, 2015 at 18:07 comment added david TLS and SSH often use block ciphers, which means that a longer password will only cause the encrypted message to be longer when it overflows a block (for example, an 8-byte boundary). However, if the password is typed as part of an interactive session (terminal over SSH, or VNC over SSH, ...), one packet will be sent for each keystroke, which discloses almost as much information as audio of the user's key-clicks.
Jun 23, 2015 at 17:21 comment added supercat Even if the length didn't leak, an attacker who doesn't know that someone's password is exactly e.g. nine characters long could start by guessing all possible shorter passwords, since the number of possible passwords less than nine characters is significantly less than the number of nine-character passwords.
Jun 23, 2015 at 15:13 history answered Tom Leek CC BY-SA 3.0