124

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?

Crizly
  • 2,597
  • 4
  • 18
  • 29
  • 8
    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**. – user10008 Jun 25 '15 at 11:25
  • 66
    Size matters. The shorter it is, the lesser you want to talk about it. – pyb Jun 25 '15 at 16:03
  • 7
    the importance of keeping the length secret is inversely proportional to the length. – hildred Jun 25 '15 at 17:37
  • 4
    Most strings length up to 17 are *exactly* length 17 (the volume of an n-ball is near the surface) – Colonel Panic Jun 26 '15 at 22:15
  • @ColonelPanic For big n – PyRulez Jun 27 '15 at 18:57

10 Answers10

157

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.

Mike Ounsworth
  • 57,707
  • 21
  • 150
  • 207
  • 8
    "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.) – Scott Arciszewski Jun 23 '15 at 14:32
  • @ScottArciszewski Knowing that a system only accepts passwords, for ex., *longer than 17* actually gives the attacker WAY LESS than a 2% speedup because the number of passwords less than 17 is minuscule compared to *17 and up*. Another point is that databases should be storing salted hashes of the passwords, in which case no length information is leaked if the db is stolen. – Mike Ounsworth Jun 23 '15 at 14:44
  • 1
    I meant: two columns `password` is a bcrypt/[password_lock](https://github.com/paragonie/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). – Scott Arciszewski Jun 23 '15 at 15:04
  • 7
    @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. – Mike Ounsworth Jun 23 '15 at 15:12
  • That's called security though obscurity. A better idea would be to store `(int) log($entropy, 2)`. – Scott Arciszewski Jun 23 '15 at 15:15
  • @ScottArciszewski ... how is that any less security-through-obscurity? You're still just changing the way you compute the value stored in the `entropy` column. Now the attacker has to match against `(int) log(zxcvbn($password), 2)`, which is still faster than `bcrypt($password)` ... unless I'm missing something. – Mike Ounsworth Jun 23 '15 at 15:20
  • @ScottArciszewski Thinking about it more, from the perspective of this thread (ie, ignoring other factors), storing the zxcvbn score next to the password hash is actually worse than storing the length because there are a lot more strings that have the same length than strings that have the same 3 decimal place zxcvbn score. Granted, `(int) log_2()` mitigates that a lot. – Mike Ounsworth Jun 23 '15 at 15:27
  • 1
    @ScottArciszewski Any estimate of the entropy of a password only gives an attacker a list of candidate users to target. i.e. "Attack Andy guy with the 6 character password, but not Frank with the 17 character password". – Steve Sether Jun 23 '15 at 15:31
  • 1
    @ScottArciszewski Nope, it also allows you to filter your brute-forcing dictionaries to only try passwords which match the given length / entropy. – Mike Ounsworth Jun 23 '15 at 15:43
  • 11
    @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. – kasperd Jun 23 '15 at 17:35
  • @MikeOunsworth `but I still wouldn't do it` in that case I think your password is exactly one character shorter than it should be. Or put differently, the security gained by increasing the length of your password by one single character far outweighs the possible security lost by telling everybody how long the password is. Personally I have no problem telling the world that I use a password which is 32 characters long and has 130 bits of entropy. – kasperd Jun 23 '15 at 17:42
  • 6
    @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. – Patrick M Jun 23 '15 at 21:20
  • @PatrickM Tweaking the estimation algorithm to work around the issue would indeed be security through obscurity. But the variation doesn't have to be deterministic. Simply adding a random number in the range from 0 to 1 would suffice to eliminate the leak and avoid the discontinuity associated with rounding. – kasperd Jun 23 '15 at 23:26
  • Keeping in mind that very little of the password input space is actually used when manually creating passwords, one should expect a strategic adversary to attempt cracking passwords regardless of length. The 1.6% speedup is a small advantage precisely because the input space is *very large*. If the input space was very small (it is), and well known to the attacker (we don't know if that's the case), then attacks could be facilitated much more than by a mere 1.6% (but we can't quantify how much for lack of data). – Steve Dodier-Lazaro Jun 24 '15 at 11:43
  • You should remove "according to wolfram alpha". Anyone can verify your claim in seconds with one line of python, octave, mathematica, or whatever. That's like saying, "according to wolfram alpha, 1+1=2". – Elliot Gorokhovsky Jun 25 '15 at 01:10
  • @RenéG There, edited to be less offensive to you. I'm leaving links to the calculations though, because that's not an obvious calculation for people without a strong math background. Also, it's not a calculation that you can do easily in most programming languages since 62^17 (or 95^17) is WAY more than 2^32, and so will cause int overflows. – Mike Ounsworth Jun 25 '15 at 01:17
  • I didn't mean to be a pedant :) I didn't downvote, it was just my opinion. Either way, doesn't really matter. Though to be fair, someone who doesn't know how to compute that sum shouldn't be working with computers, simple geometric series. The background is just high school math. – Elliot Gorokhovsky Jun 25 '15 at 01:21
  • @ScottArciszewski just don't have mandatory password resets anyway, please. They actually decrease security. – o0'. Jun 26 '15 at 09:29
  • I don't in any of my applications. I'm speaking strictly hypothetically here. – Scott Arciszewski Jun 26 '15 at 10:17
  • "if they know your password has exactly 17 characters, then they can skip all the passwords with length less than 17". They can also skip passwords with length *greater than* 17. I can't seem to see how your analysis considers this. What am I missing? –  Jun 29 '15 at 10:46
  • @MaskedMan The simplest brute force attack would try passwords in order of increasing length. So passwords of length 18 and above would never be tried anyway, because the attacker would find the password while trying those of length 17 and stop once the password has been found. – kasperd Jun 29 '15 at 21:44
  • @MaskedMan You are correct, given the large number of password cracking programs out there, trying to guess what order they will try passwords is a losing battle. This math was meant to be a rough first look at understanding the problem, not a definitive answer. As I note in my second section, this math is quite bad for dictionary attacks, but it it still solid for cracking a completely random password like `=Wm)Z;]A@5m*vRhD` – Mike Ounsworth Jul 01 '15 at 17:14
61

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.

Tom Leek
  • 168,808
  • 28
  • 337
  • 475
  • 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. – supercat Jun 23 '15 at 17:21
  • 9
    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. – david Jun 23 '15 at 18:07
  • 3
    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. – Tom Leek Jun 23 '15 at 20:05
  • 1
    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... – AviD Jun 23 '15 at 20:16
  • 1
    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. ;) – Ernie Jun 23 '15 at 21:39
  • 2
    @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 '15 at 18:06
  • 1
    @david: Yes, leaking time between keypresses is a serious disclosure, there's a lot of mutual information there. – Ben Voigt Jun 24 '15 at 20:12
  • 3
    @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. – Steve Jessop Jun 25 '15 at 08:34
  • @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). – xyz Jun 25 '15 at 08:45
  • 4
    @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. – Steve Jessop Jun 25 '15 at 09:04
18

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.

Steve Sether
  • 21,480
  • 8
  • 50
  • 76
  • 1
    I would hardly call information which can save a lot of attacher's time 'useless' :) – Cthulhu Jun 24 '15 at 08:25
  • 6
    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 '15 at 14:25
  • 3
    Or say it's shorter, attacker will think it's easy to crack, and spend a couple of months generating heat, producing nothing. – Display Name Jun 25 '15 at 09:34
  • Or lying to waste effort: I have an 18 long(when really it's 16... , or vice versa) – WernerCD Jun 28 '15 at 18:05
11

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.

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.

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.

Community
  • 1
Peter
  • 3,620
  • 3
  • 13
  • 24
  • 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. – Luis Casillas Aug 25 '16 at 20:31
7

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.

Vladislavs Dovgalecs
  • 191
  • 5
3

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)
WoJ
  • 8,957
  • 2
  • 32
  • 51
  • We can use the [Diceware](http://diceware.com) 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 07 '16 at 14:55
1

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.

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

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.

gnasher729
  • 1,823
  • 10
  • 14
  • 1
    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) – Display Name Jun 25 '15 at 09: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. – Peter Jun 27 '15 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. – gnasher729 Jun 29 '15 at 14:29
  • iPhone is not an example, they have weak hardware and also may have artificial limitations. I got that from https://howsecureismypassword.net/ – Display Name Jun 29 '15 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. – Aidiakapi Jun 29 '15 at 15:42
  • @Peter the user may not know which hash method is used on a server of Some Other Company. – Display Name Jun 29 '15 at 15:43
  • @Aidiakapi An iPhone takes about 80 ms of calculations to test one passcode (recent models add hardware-imposed artificial delays in case of repeated incorrect guesses). See for example [iOS Security, October 2012, by Apple](https://www.apple.com/br/ipad/business/docs/iOS_Security_Oct12.pdf), page 9 in the PDF. – user Mar 07 '16 at 14:58
  • @Michael Kjörling That's only for its own security. You can just create an app to calculate hashes for brute forcing passwords for other scenarios. I'm also fairly sure modern iPhones support GPGPU, allowing again GPU based brute forced, several orders of magnitude faster than CPU based approaches. Nonetheless for cracking the iPhone's password itself, that is indeed some interesting security. – Aidiakapi Mar 07 '16 at 16:04
1

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.

Quora Feans
  • 1,861
  • 1
  • 12
  • 20
-3

Yes. It is VERY crucial. A program called Crunch generates wordlists for you. Ranges like 1-17 characters will take up 15610 petabytes! However, if a hacker know your password is exactly 17 characters, it will take a lot less. That is why it is crucial.

The Broken Ace
  • 2
  • 3
  • 3
    Exactly 17 characters takes the same amount of data to store as everything up to and including 17 characters. Everything 1-16 characters is just a rounding error compared to the size of 17. – Bryan Boettcher Jun 29 '15 at 18:14
  • Oh. I didn't know that. – The Broken Ace Jun 29 '15 at 18:52
  • It's pretty crazy the search space for a 17 character password. Think about it, if you have 17 characters (of 62 possible characters per space), you have 1-16 for *each* of the 62 characters in the 17th space. That by definition makes all the 1-16 characters at most 1/62th of the space of just 17. – Bryan Boettcher Jul 01 '15 at 14:27