Does someone knowing that you have a password length of say 17 make the password drastically easier to brute force?

• In an idealized world, with a known character set and without dictionaries or other complex methods to generate passwords, not knowing the length of the password has the same cost to the attacker as one additional character in the character set. Jun 25, 2015 at 11:25
• Size matters. The shorter it is, the lesser you want to talk about it.
– pyb
Jun 25, 2015 at 16:03
• the importance of keeping the length secret is inversely proportional to the length. Jun 25, 2015 at 17:37
• Most strings length up to 17 are exactly length 17 (the volume of an n-ball is near the surface) Jun 26, 2015 at 22:15
• @ColonelPanic For big n Jun 27, 2015 at 18:57

Well, let's start with math: If we assume that your password consists of lowers, uppers, and numbers, that's 62 characters to choose from (just to keep the math easy, real passwords use symbols too). A password of length 1 has 62 possibilities, a password of length 2 has 62^2 possibilities, ..., a password of length n has 62^n possibilities.

So that means that if they know your password has exactly 17 characters, then they can skip all the passwords with length less than 17, and there are only 62^17 passwords to try.

But how many passwords are there with length less than 17, compared to 62^17?

Well, if we add up 62^n and divide by 62^17 we get (sum from n=1 to n=16 of 62^n ) / 62^17 = 0.016 (link to calculation), so checking only passwords of length 17 is only 1.6% faster than checking all passwords up to length 17

If we have a password scheme which allows all 95 printable ASCII characters, then the savings from not having to try passwords shorter than 17 drops to 1.06% (link to calculation).

An interesting mathematical quirk about this ratio of the number of passwords shorter than n, over the number of passwords of length n, is that it doesn't really depend on n. This is because we're already very close to the asymptote of 1/95 = 0.0105. So an attacker gets the same relative, or percentage, time savings from this trick regardless of the length of your password; it's always between 1% - 2%. Though, of course, the absolute time that it takes grows orders of magnitude with each new character that you add.

The maths above assume a simple brute-forcer which will try a, b, c, ..., aa, ab, ... Which is a good(ish) model for cracking properly-random computer-generated passwords, but is a terrible model for guessing human-generated passwords.

Real password crackers are dictionary-based, trying words (and combinations of words) from the English dictionary, lists of leaked passwords, etc, so those calculations should be taken with a grain of salt.

Another effect of knowing your length is that they don't have to try any passwords longer than 17, which for brute-forcing algorithms that try combinations of dictionary words, could actually be a huge savings.

As mentioned by @SteveSether, @xeon, and @CountIblis, disclosing the length (or entropy) of a password can also effect whether an attacker even attempts to crack your password by deterring them away from strong passwords and instead attracting them to weak ones. So if you know you have a strong password, then disclose away! However, disclosing the password lengths (or entropies) for all users in a system has the effect of making strong passwords stronger, and weak passwords weaker.

Bottom Line:

Telling someone the length of your password isn't the worst thing you can do, but I still wouldn't do it.

• "Telling someone the length of your password isn't the worst thing you can do, but I still wouldn't do it." There are use cases where storing this information is useful. (Longer passwords -> more time between mandatory password resets.) If a database is compromised, this can be leaked. A ~2% crack optimization isn't a significant draw-back versus a scheme that rewards longer passwords. (Note: I'd actually be storing the zxcvbn entropy estimate rather than the length, but that can be approximated too.) Jun 23, 2015 at 14:32
• I meant: two columns `password` is a bcrypt/password_lock hash, `strength` is a zxcvbn entropy estimate of the password for determining when to force the user to do a mandatory password reset (unilateral 30 days is annoying, let's use Pavlovian conditioning to reward stronger passwords). Jun 23, 2015 at 15:04
• @ScottArciszewski Fair. You are in effect keeping two "hashes" for each password: the bcrypt hash, and the zxcvbn entropy. Since zxcvbn is much faster to compute than bcrypt, an attacker only has to do the 100,000 (or wtv) salt-and-hash iterations of a candidate password if the zxcvbn scores match exactly. This is a HUGE advantage to the attacker. Since zxcvbn is open source, I would suggest that you modify the algorithm slightly so that at least the entropy values in your db won't match exactly with those computed by the standard implementation. Jun 23, 2015 at 15:12
• @ScottArciszewski Instead of storing the entropy estimate, I think it is much better to store the computed expiry time. Additionally a bit of randomization like suggested by Mike will ensure that an attacker that manages to figure out the exact permitted lifetime of a password won't figure out the exact entropy estimate. Jun 23, 2015 at 17:35
• @MikeOunsworth I'm not going to say that storing (int) log(\$entropy, 2) is safe, but if zxcvbn(\$password) is a floating point number, then storing the first is probably safer, because you are truncating off a lot of precision. This is reducing the amount of data available to the attacker. This is like the difference between saying, "Here is the crc32 of my password" and "Here are the first 2 digits of the crc32 of my password." Both might be a bad idea, but the first is much worse. On the other hand, tweaking zxcvbn without changing the precision would be security through obscurity. Jun 23, 2015 at 21:20

Apart from the maths detailed by @Mike, consider also that the password length leaks all over the place:

• When it is typed, a sneaky bystander can learn it, either by counting the '*' on the screen, or listening to the keystrokes (in the latter case, he can record the sound with his smartphone and play it as his leisure).

• In a classic "Web browser" scenario, the user name and password will be sent to the server through some HTTPS POST. The SSL layer will encrypt the data, but SSL does not hide the data length, so a passive network observer will also learn the password length.

• Both the user-side interface, and the receiving system, will process the password with functions whose execution time and memory access patterns will depend on the password length. Attackers who can do timing measures will usually be able to infer the password length from these measures.

Therefore, a sane approach is to consider the password length as public data. Some attackers won't have access to it (the kind of attackers who just grabbed a copy of the server database); others will know it. It is very hard to know "how much secret" the password length is, and since security is all about quantifying things, it is best to just assume that all attackers may know the password length. Believing that you can keep it secret, and estimating security based on that notion, would be overly dangerous.

• 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 18:07
• 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 20:05
• @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.
– xyz
Jun 24, 2015 at 18:06
• @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 25, 2015 at 8:34
• @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 9:04

So if your password is very long (17 characters in your example) it's largely useless information. If the password is short, (6 characters), it tells an attacker that you might be worth attacking. Attackers go after the easiest targets.

• I would hardly call information which can save a lot of attacher's time 'useless' :) Jun 24, 2015 at 8:25
• The corollary would be: If possible, announce a password length that is significantly larger than that of your real password. If an attacker ignores it, no harm is done. If they believe it, they might abstain from trying to crack your password (or even try the wrong password length).
– Dubu
Jun 24, 2015 at 14:25
• Or say it's shorter, attacker will think it's easy to crack, and spend a couple of months generating heat, producing nothing. Jun 25, 2015 at 9:34
• Or lying to waste effort: I have an 18 long(when really it's 16... , or vice versa) Jun 28, 2015 at 18:05

I disagree with the accepted answer. It's true that the password length is nearly useless if all passwords are randomly created by a machine. This no longer holds if passwords are created by humans in the usual way: Based on one or more dictionary words, mix upper case lower case, substitute some characters with numbers or special characters, and add prefixes and suffixes (e.g. "!1"), etc.

Let's look at 2 scenarios, one is we have 10'000'000 passwords hashes and want to find as many matching passwords for these hashes as possible. The other is one password hash and we want to crack it. In both scenarios the difference turns out to be significant. As usual, all information can be abused in an attack, even if it doesn't seem so at first sight.

## Scenario 1: Crack many out of 10'000'000 password hashes with limited resources.

We can just try bruteforce attacks on all of the password hashes with no way of distinguishing them if we don't know the password length.

If we use an exhaustive bruteforce attack (which is guaranteed to find the password) knowing the password lengths will only offer a very minimal gain. Why? Bruteforcing all 7 digit passwords takes about 1-2% as long as brute forcing all 8 digit passwords. The only thing we gain by knowing the length is that we don't need to brute force all 7 digit (and smaller) passwords if we already know that the password has 8 digits. Except that a bruteforce attack requires near infinite resources (computational power and/or time) and therefore isn't something we can or will do.

If we look at all the benefits combined, the exact gain we receive from knowing the password lengths depends on the speed of our method to test "likely" passwords, the respective success rate of our method to test likely passwords for each password length, the distribution of password lengths in the password hash collection we want to crack, and the amount of resources we have available (calculation speed, time). But by knowing the lengths of the passwords we can easily increase the number of passwords we find with a given amount of resources several times over - if the numbers work strongly in our favor, we can possibly reduce the resource cost to crack 30% of the passwords by an order of magnitude or more.

## Scenario 2: Crack a single password in a targeted attack

Not knowing the length of the password, we need to distribute our resources between brute forcing all keys with a short length and testing likely passwords with a longer length. Assuming we spend half our resources on each, knowing the password length allows us to completely pass on one of the 2 and therefore double our available resources.

We also gain additional information which can be extremely valuable in a targeted attack:

• If the password is short enough to brute force it, we can give an upper bound on how long it takes us to get the password. This can cause us to attempt some attacks we otherwise wouldn't even consider.

• We also can calculate a likelihood of cracking the password at all. If we know we are unlikely to crack the password we can spend our resources on finding other ways to compromise the system.

• If we have 2 different passwords from the same user we can see if there is a chance they are actually the same password. If they vary by only 2-3 digits we can make an educated guess that the longer password might be the same as the shorter one, plus a prefix or suffix.

• If we gain even more info about the password, it may result in a gain that is a lot more than the 2 pieces individually. For example if we find out the password is a single word from the Oxford dictionary, you still have a chance to keep the password safe if for example we can only brute force one password per minute. But if we also know the password length is 17 digits, it's game over.

• It looks like your disagreement with Mike Ounsworth's accepted answer very much rests on this: he assumes that the passwords are selected uniformly at random from the full set of strings, but you do not, you assume that they're chosen by people in the way people do. It would help your case, I think, if you highlight the differences in the assumptions. Aug 25, 2016 at 20:31

Revealing the length of the password does influence. If your password is weak (short password), an attacker may focus on cracking it. If the password is strong (long password), an attacker might explore other vectors of attack. So the knowledge of the length of password allows a hacker to choose a better strategy while saving time.

In addition to the answers which give a good overview of your question, there is one more thing to take into account: when making your risk assessment you must assume that the attacker knows everything about the methodology you use to build your password.

In other words, if your password is composed of four average English words glued together, all lowercase (à la xkcd) then you must assume (differently that xkcd does it, BTW) that the attacker will get the relevant dictionary and try only combination of four words.

You now have a key space (number of possibilities) which you put against the time needed to check its elements at [a number related to specific technologies and environments] tries/second - and that gives you the statistical time your password will survive an attack.

Now you decide if this is long enough, with your own criteria (password life cycle, time people work with that account, age of the universe, ...)

If we take the xkcd example, that would be

• the average vocabulary of an English speaker is around 12,000 words. Let's make it half of that (so 6,000)
• this makes 6000^4 =~ 10^15 combinations
• let's assume 1000 test/s for an online attack - this is 10^12 seconds = 20,000 years
• an offline attack will be much more effective. How much depends on many things, specialized GPU cracking can attack a hash in the range of 10^9 tests/s, which brings down the time for such a password to 15 days. This assumes, though, that the hashing was not correctly designed (hashing a password should take a long time)
• We can use the Diceware dictionary as a guideline. That's 6^5 = 7,776 words. log2(7776) ~ 12.9 (bits). Diceware assumes that words are generated in an independent, random, evenly distributed fashion (usually using physical dice, hence the name).
– user
Mar 7, 2016 at 14:55

Deliberately disclosing the password length, provided you only use very long passwords will, as Steve Sether points out in his answer, make it less likely that hackers will try to guess it. So, you actually enhance security by deliberately leaking that information about your password.

• I guess it's technically true, but the increase of security is so very nearly zero that I'd normally discount it. Jun 24, 2015 at 13:50
• or they may try to hack it in a different way. brute force for all passwords <= 8, social engineering for passwords > 8. Jun 24, 2015 at 15:47

An attacker will not use a brute force attack, trying every possible password, but try more likely passwords first. A totally random eight letter password may be harder to crack than a simple-to-guess seventeen letter password.

As a result, the attacker will not try all short passwords first, but will try passwords of various lengths throughout the attack. So if you have an eighteen letter password "hellohellohello123" you are not safe; a totally random eight letter password may be safer.

The hard eight letter password is harder to guess because the attacker also tries things like "hellohellohello123" before checking all eight letter passwords. If you tell the attacker the password length, that bit of correction goes. So the loss is much worse than then 1.26% mentioned earlier.

• True in general, but 8-length passwords are so easy to crack by brute force that they are not a good example here. (3 days if using all kinds of characters, 11 minutes if using only lowercase latin and digits) Jun 25, 2015 at 9:39
• @Sarge Depending on the hash function, its parameters, and the available computational resources to crack it, brute forcing an 8 digit password can take anywhere from (almost)zero to (almost) infinity time. A general statement that it takes 3 days to crack an 8 digit password can not be made. If someone uses a hash for which a 8 digit password can be cracked in 11 minutes by a realistic attacker, they clearly chose the wrong hash. Jun 27, 2015 at 16:53
• @SargeBorsch: Where do you get that from? For example, an iPhone takes about 0.1 seconds to check one passcode, and there is absolutely no way around this. Even 8 digits takes 3 months to crack. Jun 29, 2015 at 14:29
• iPhone is not an example, they have weak hardware and also may have artificial limitations. I got that from howsecureismypassword.net Jun 29, 2015 at 15:34
• @gnasher729 Have you ever ran a brute force app running on the GPU? On my old GPU 4 years ago it hashed 4 billion passwords a second. An iPhone is slow, yes, but 0.1 seconds seems exaggerated, it's probably closer to 0.1 ms. Jun 29, 2015 at 15:42