Is keeping your password length secret critical to security?
Does someone knowing that you have a password length of say 17 make the password drastically easier to brute force?
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.
Telling someone the length of your password isn't the worst thing you can do, but I still wouldn't do it.
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.
Revealing your password length reveals something about the strength of your password. So you're in essence giving someone a hint about how hard it might be to guess.
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 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.
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.
Instead we test a series of "likely" passwords for each password length. One way to do this is with a dictionary attack. Testing likely passwords is several orders of magnitude cheaper than using exhaustive brute force, but it has a huge disadvantage: Once we've tried all "likely" 7 digit passwords against a password hash, yet did not find the matching password, we do not know if the matching password for this password hash is longer than 7 digits. So unless we know for sure the password is not longer than 7 digits, we still have to test that password hash against all "likely" 8 digit passwords, 9 digit passwords, 10 digit passwords, etc - and when testing likely passwords, just like exhaustive bruteforce, the cost of testing longer passwords increases exponentially. Since we now know the password is 7 digits long, we don't have to test it against likely 8, 9, 10, 11, 12 digit and even longer passwords, saving a truly massive amount of work.
It gets better. Once we tested all likely passwords up to a length of, say, 20 digits, we can now spend our remaining resources on a brute force attack on those password hashes with a small password length which our previous search for "likely" passwords did not crack. Say we have 2'000'000 uncracked password hashes remaining and 100'000 of these have passwords with less than 6 digits. Keep in mind we have a limited budget. 6 digit passwords are cheap to crack. But because we know which 100'000 are 6 digit or smaller, we now need to brute force 100'000 6 digit passwords in order to crack 100'000, instead of brute forcing 2'000'000 passwords to crack 100'000 6 digit passwords. That's 5% of the work for the same result!
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.
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.
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
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.
Anything that reduces the entropy of your password reduces its strength.
It might be that even when you disclose the password length, the remaining possible password's pool is still large enough.
Regarding a concrete example, the set of all passwords of length 17 is surely strong enough against almost all attacks. Provided you did not reveal other details like "My password of the length 17 contains the name of my cat kitty, which no one knows."
Length 17 implies 272843561753653169767435615050624325866274580142388791900214521038955085904188409449281578168966401 combinations (considering 80 possible characters - adding alphanumeric and special characters). I am pretty sure this is enough, given our current processing power. The number above is of the order of magnitude of a digit followed by 98 0s.