3

Reading this topic How critical is it to keep your password length secret? following scenario comes to my mind:

Assume I've a web application (PHP written using password_hash()) using salted password hashes to save user passwords. A user tries now to login. The server now has to do some tasks:

  1. Calculate hash of provided password (of course with cost factors)
  2. Compare hash with saved hash

Assuming that I can save the length of a password without any security issues, I could change the taskflow:

  1. Compare length of provided password with saved length (does not match -> return)
  2. If match calculate hash of provided password (of course with cost factors)
  3. Compare hash with saved hash

What do you think? Would this be "economic" because I save computing time/resources (or does it slow down the process overall, because it would only save time if no valid password was provided)? Or would that be an security issue?

  • Contrary to what we see in movies (big blinking and alerting messages "Access granted" once the correct password is entered as if this is something extraordinary), entering the correct password should be the most likely event in real life. Therefore, you are trying to save time at most in a niché case (for legit users) while giving away information to intruders. – Hagen von Eitzen Jun 26 '15 at 16:14
7

Yes there is a security issue. You stand the risk of inadvertently leaking the length of the passwords using this approach.

An attacker could abuse this to determine the length of a password using a form of timing attack.

Since calculating the hash is computationally more expensive than comparing the length of the provided password with the stored length we can assume that the length comparison will execute much faster than the hash calculation and comparison and therefore return a result to the user much faster (we are speaking about milliseconds here - but what is important, is that it is measurable).

Now, the attacker can simply start submitting passwords of different lengths and measure the time it takes to get a response (adjusting for network latency and other factors) and measure the response times. Since the server will take longer to respond when actually comparing the hash the attacker will know that the length of the password is correct when the response is relatively slower than in previous guesses. Having the length of the password then makes it much easier for the attacker to start guessing at the correct password.

If computation on the server is really an issue for you, you can mitigate this risk by ensuring that the response is only returned after a fixed amount of time. This way the time the response takes leaks no information to the attacker as it has no bearing on what computation is being made in the background.

Everything considered I'd say that the risks of doing something like this definitely outweighs the rewards.

  • thanks for your answer. considering the topic I mentioned knowing the length of the password is not so critical. I just thought about optimizing some processes (Why I should waste resources when I could even save a (very) small amount) – Danny. Jun 26 '15 at 10:54
  • My pleasure. I get where you are coming from and appreciate the essence of the question better now. Let's just say that I, like the author of the referenced answer, will not like it if the length of my password is known. Also considering the average users passwords habits (short simple dictionary based passwords), I'd wager that knowing the lengths of the passwords is a bigger concern than that post alludes to, especially when considering offline hash cracking. – ilikebeets Jun 26 '15 at 11:13
  • Nothing to say except: Jip - you're right. I think it would not be important if the average user uses passwords with length >12 of "random" chars. But if the attacker knows the password has a length of 6 a dictionary attack would have a bigger chance then to an password with length of 14. So he could concentrate on them. – Danny. Jun 26 '15 at 11:18

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.