Should I vary the length of my completely-random passwords for the best security?

Question

I use LastPass comprehensively, and for each new site/password I almost always have it generate a random password of the same number of characters, allowing letters, numbers, and symbols (except when prevented by password forms that disallow that length or certain symbols). Today, it occurred to me that using the same password length everywhere could itself be an issue.

Let's say a malicious agent owns a site that I have registered at, and has kept the original password. Just seeing the password would make it obvious that I'm probably using a random one. But if that site maliciously wished to target other accounts I may own, and he guesses that I generally used passwords of the same length, he might have a leg up on brute-forcing my password at other sites. Therefore, would my using a variety of lengths yield appreciably more security than using just one length?

It's convenient to not change the number of characters that LastPass generates. And most sites do have a limit on the number of characters which is lower than I'd like. I also don't want to just add more characters for no reason, because occasionally I do have to type one of these passwords on my mobile phone. The other day when a site said the password length limit was 60, intrigued, I created a 60-character random password, But later, I had to type this password on my phone and while I did it correctly on the first try, it was a lengthy and painful process.

It occurs to me that just adding some number of characters to my typical length will probably provide all the extra entropy needed to remove any weakness from an attacker knowing I use the same length anywhere. But I'd be interested for some knowledgeable people to comment on this.

How many extra digits need I use so that my passwords are as secure as using a variable number of characters? For example, if I were using 15 characters all the time, how many more characters would I have to add to have the same entropy as if I normally randomly used 10-15 characters? Though, the security of 10 characters feels too low in the first place, and always using 15 seems safer. So I'm conflicted.

What's a reasonable way to look at this? Should I:

1. Use different lengths at different sites
2. Increase my characters (I don't use 15, but some other number)
3. Or just don't worry about it as long as my length is sufficient (and what length would you say is sufficient to be theoretically uncrackable* for the next 20 years)?

For what it's worth the full character set LastPass uses is 70 characters: A-Za-z0-9!#^&$@*%.

Re: uncrackable: I realize the crackability of a site is not just dependent on the password itself, but also on the site's security practices such as means of storage, whether it keeps the original password or a hash, the particular hash algorithm and its number of bits, whether the attacker has gained access to the hash, whether the hash is salted and the attacker knows the salt, whether the site rate-limits or locks accounts after experiencing apparently hostile attack behavior, and so on and so forth including the vigilance and knowledge of its employees to resist social engineering and all the rest of that jazz. This question, instead, is merely about the scenario where the only attack vector is to try every possible password and see if the site accepts it.

Answer 1

Therefore, would my using a variety of lengths yield appreciably more security than using just one length?

No, the only thing it will accomplish is to make the shorter ones weaker.

For why hiding your password length doesn't matter, see this question (disclaimer, the accepted answer is mine):

How critical is it to keep your password length secret?

---

Thought experiment: how long a password is physically uncrackable? Well, the sun contains roughly 1.2x10⁴⁴ Joules of nuclear fuel. Let's assume we had a magic register of bits that required only 1 eV to flip a bit (1 electron volt = 1.602×10⁻¹⁹ Joules). It turns out that with a register of 208 bits, counting from 0 to 2²⁰⁸ would require you to consume the energy equivalent of the sun. So, assuming you're making passwords using the 95 printable ASCII characters, then consuming the sun would crack you a 208 bit ~= 32 character password.

How "magical" is this register? Well according to Table 1 (p. 6) of this paper:

An Accurate Instruction-Level Energy Consumption Model for Embedded RISC Processors

one ARM assembly instruction (ADD, SUB, XOR, ...) consumes about 300 pJ ~= 3.0x10^-10 Joules ~= 1.8x10⁹ eV per instruction on a low-power embedded device. Given this efficiency, consuming the sun would crack you a 28 character password.

If you're using randomly-generated passwords, then I don't see any reason that anybody should ever use more than 32 chars, but you can probably get away with a lot less against attackers who don't have a sun to spend cracking your password.

Answer 2

I wouldn't bother with varying the length. 15 characters from a 95-character space is probably more than sufficient - and varying the length won't buy you as much as simply increasing the length.

Using even a simplified character set C (the alphanumeric character set) = 62 characters, H (hashing speed of the attacker) = 100TH/s, and Y (the time that you want the password to resist brute force) = 100 years:

ceil( logC (H * Y * 31556926 [sec/year]) )

... the non-Moore’s-law-aware length that would fit that risk model is 14 characters.

Taking Moore's law into account, using the anrieff.net calculator, such a password would resist brute force for 16 years 2 months.

Increasing the character set to the printable ASCII space and using 20 characters, the Moore's-law-aware time jumps to 79 years (in case you want your password to outlive you). (Keep in mind that this is the time to fully exhaust the space. Since half such passwords would be guessed in half of that time, you'd need to size according to your threat model).

Answer 3

A bruteforce attack becomes significantly harder to crack once you use more characters. However it might be a security risk, the risk is so low compared to the actual time it takes to, for example, crack a 20 character long password. Think about how much options you have for that...

You have 26 letters in the alphabet, 10 digits and lets use 20 special characters for this example. That means you have 56 characters to choose from, which gives you 56^20 different possible passwords. That is so hard to crack that even knowing the amount of characters, it should be really safe to stick to them. Remember that most common websites have built in protection to stop brute force attacks as well.

So yes, there might be a slight security risk but no significant impact.

Answer 4

The optimal password generation strategy is to choose passwords randomly with equal likelihood (uniform distribution) out of a prohibitively large set (one that the attacker cannot search in any reasonable amount of time). It doesn't matter if some members of that large set are longer or shorter than others. It also doesn't matter if they're all the same length—if you've nailed the uniform selection and the prohibitively large set you don't need to worry about anything else. (Except usability, but that's a story for another day.)

As a practical matter, using a fixed length n is just simpler, because you can then just break the password generation problem into the independent uniform random choice of n characters. If you wanted to pick variable-length passwords uniformly at random with length up to n, that's more complicated, because in that case you have to design your algorithm so that it's not biased toward choosing passwords of any particular length. You have to take care that if passwords of length i <= n are p fraction of the total password space, then you choose a password of length i with exactly p probability. This isn't a super-hard problem by any means, but you gain nothing out of it that you couldn't just by choosing a slightly longer fixed-length password space.

15-character passwords from a 95-character set, chosen uniformly at random, is about a 99-bit security strength (about 6.6 bits/character). That's plenty strong for authentication into websites whose codebase and security measures you don't control. Even dropping down to 12 sounds fine (79-bit).