If an attacker who can watch network traffic knows a victim's username and can figure out which request is a login, then the size of the login request will reveal something about the password length.

Is this a problem? Should login requests be padded?

(My guess is that it's not a problem. If the revealed maximum length is something attackable in reasonable time, then the attacker could have already just done it.)

2 Answers 2


No, this is not a problem.

1. Brute-forcing would start with shorter passwords

Depending on implementation there can be padding, see the RFC. But even if there is no padding in protocol, you don't have to use it.

Suppose an attacker can send as many requests as technically possible, and the application can process them without any limits. We don't consider trivial cases when user account is blocked after several failed attempts and other measures that prevent brute-forcing.

Suppose passwords consist of 62 characters. How many attempts will the attacker need to test all possible password candidates?

  • 10 characters: 10^62 candidates
  • 11 characters: 11^62 candidates
  • 12 characters: 12^62 candidates

To check all candidates of length 11 there are 62 times more attempts needed than for all candidates of length 10 (in the worst case). For the length 12 there are 3844 times more attempts needed than for the length 10. Etc.

Means, it makes sense for an attacker to test first shorter passwords, than longer ones, because for shorter passwords it takes essentially less resources than for the longer ones.

Thus, revealing password length does not give the attacker any essential advantage. The shorter the password the higher is the probability of successful brute-forcing.

2. Kerckhoffs' Principle

You should assume that the attacker knows everything including password length of particular user, and that only specific characters are not known. Thus, revealing password length will not give much advantage attacker.


In many cases, the entire HTTP request (not just the password) is padded, by virtue of the fact that the request is sent using SSL/TLS. At the heart of SSL/TLS, symmetric AES encryption is used. AES requires blocks that are each 16 bytes in length. So all requests must be padded to a length that is a multiple of 16 bytes, before they can be sent over SSL/TLS. However, there are some exceptions to this, as pointed out by @forest and @nobody in the comments below.

  • It may be useful to note that TLS compression should be disabled for this to be secure.
    – forest
    Nov 13, 2021 at 1:06
  • 1
    Also note that stream ciphers like ChaCha20 or AES-GCM won't be padded
    – nobody
    Nov 13, 2021 at 1:19
  • @forest and nobody, Thanks for pointing out these caveats. I've amended by answer to reference these.
    – mti2935
    Nov 13, 2021 at 2:43
  • These says they are rule rather than exception. TLS 1.3 for instance uses only AES-GCM and Chacha20-Poly1305 and maybe AES-CCM (not sure about this one) non of which requires padding. And many servers I.work with use TLS 1.2 but they also seem to prefer AES-GCM Nov 13, 2021 at 12:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.